Проверка состояния сервера

Skip to end of metadata
Go to start of metadata
Вы просматриваете старую версию данной страницы. Смотрите текущую версию. Сравнить с текущим  |   просмотр истории страницы

Диагностика в командной строке

1. При каких либо сбоях требуется проверить состояние сервера и работу всех служб. Делается это командой 

server_check

В ответ будет выведено состояние всех служб биллинга. Все службы должны иметь состояние [ OK ]. Если где-то есть сбой, то при обращении в поддержку укажите сбойную службу.

2. Для проверки базы можно посмотреть логи которые ведет система:
лог базы биллинга

cat /app/asr_billing/var/log/firebird/firebird.log

В выводе особое внимание обратить на строки содержащие примерно такие блоки текста

2.1. Повреждена целостность БД, серьезный сбой. Вероятно потребуется восстановление из бекапа:

Database: /mnt/var/db/billing.gdb
database file appears corrupt (/mnt/var/db/billing.gdb)
wrong page type
page 1647 is of wrong type (expected 7, found 5)
internal gds software consistency check (error during savepoint backout (290), file: exe.cpp line: 4026)

2.2. Биллинг не может найти БД, вероятно биллинг в safemode:

Database: /mnt/var/db/billing.gdb
I/O error for file "/mnt/var/db/billing.gdb"
Error while trying to read from file
No such file or directory

2.3. Отдельная запись в таблице помечена как поврежденная:

Database: /mnt/var/db/billing.process.gdb.13836
Record 1002 is marked as damaged in table RDB$RELATIONS (6)

Ошибки тестов

check_billing_db_size.sh

- check_billing_db_size.sh:  ERROR(1)                      [СБОЙ ]

    2017-03-03 13:38:47 Чрезмерно большая база данных биллинга

2017-03-03 13:38:47: /usr/local/monitoring/check_billing_db_size.sh ERROR(1): 2017-03-03 13:38:47 Чрезмерно большая база данных биллинга

Ошибка происходит при увеличении размера БД до 10Гб. Почему так происходит, описано в справочной документации firebird.
Со временем база может достичь данного размера по той простой причине, что место на диске не очищается при удалении записей из базы данных, так как это создаст лишнюю постоянную нагрузку на диск и ОЗУ. Записи в БД добавляются постоянно - любые события, происходящие с абонентами, их лицевыми считами, оборудованием, добавляются в стэк событий, обрабатываются воркером, после чего очищаются.
Для решения проблемы Вам необходимо [создать бэкап, после чего восстановиться с него же].

Диагностика в командной строке

Рписание диагностики находится в соответствующей статье.

Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.