Проблемы с базой после переноса на production сервер
Модераторы: kdv, Alexey Kovyazin
Проблемы с базой после переноса на production сервер
Ситуация выглядит так:
Есть база размер 300 Mb на разработческом сервере (на Linux CentOS). Сайт на ней крутится на очень приличной скорости - проблем нет. Переношу ее с помощью backup-restore на production, проверяю gfix -v -full моя_база - никаких предупреждений. Хорошо. Запускаю сайт и через некоторое время СУБД перестает отвечать на запросы к базе.
Нюансы:
1) Системы на обоих серверах идентичны по набору софта.
2) Версия СУБД: Firebird Classic 1.5.4
3) На обоих серверах крутится несколько БД. Т.е. отличие только в том, что на DEV сервере нет нагрузки. (Нагрузка на production сервере даже близко не подходит к пределам возможностей железа)
4) Самое непонятное для меня: при попытке подключиться к production базе с помощью IBExpert, он зависает на бесконечно долгое время и всегда на одном и том же месте - "Loading generators....", хотя (еще раз обращаю внимание) на DEV сервере с этой базой проблем нет!
Причем, после того как подвис эксперт с базой даже через shell не получается сделать ничего, т.е. к примеру команда "gfix -shut -force 0 bd" точно так же приказывает долго жить (не выводя никаких ошибок).
При этом, если заглянуть в top, то окажется, что процесс firebird висит там, жрет до 99% процессора и не собирается завершаться самомтоятельно.
В firebird.log никаких ошибок не появляется.
Собственно, бэкап-рестор делал не один раз.
Значения в генераторах стоят валидные, т.е. до предела integer-а им далеко.
Если после прочтения описания проблемы вы потеряли ход моей мысли, то подытожу:
отлично функционирующая база начинает вести себя неадекватно при переносе на однотипный сервер, но работающий под нагрузкой.
Буду благодарен за любые советы, т.к. у меня версий нет.
Есть база размер 300 Mb на разработческом сервере (на Linux CentOS). Сайт на ней крутится на очень приличной скорости - проблем нет. Переношу ее с помощью backup-restore на production, проверяю gfix -v -full моя_база - никаких предупреждений. Хорошо. Запускаю сайт и через некоторое время СУБД перестает отвечать на запросы к базе.
Нюансы:
1) Системы на обоих серверах идентичны по набору софта.
2) Версия СУБД: Firebird Classic 1.5.4
3) На обоих серверах крутится несколько БД. Т.е. отличие только в том, что на DEV сервере нет нагрузки. (Нагрузка на production сервере даже близко не подходит к пределам возможностей железа)
4) Самое непонятное для меня: при попытке подключиться к production базе с помощью IBExpert, он зависает на бесконечно долгое время и всегда на одном и том же месте - "Loading generators....", хотя (еще раз обращаю внимание) на DEV сервере с этой базой проблем нет!
Причем, после того как подвис эксперт с базой даже через shell не получается сделать ничего, т.е. к примеру команда "gfix -shut -force 0 bd" точно так же приказывает долго жить (не выводя никаких ошибок).
При этом, если заглянуть в top, то окажется, что процесс firebird висит там, жрет до 99% процессора и не собирается завершаться самомтоятельно.
В firebird.log никаких ошибок не появляется.
Собственно, бэкап-рестор делал не один раз.
Значения в генераторах стоят валидные, т.е. до предела integer-а им далеко.
Если после прочтения описания проблемы вы потеряли ход моей мысли, то подытожу:
отлично функционирующая база начинает вести себя неадекватно при переносе на однотипный сервер, но работающий под нагрузкой.
Буду благодарен за любые советы, т.к. у меня версий нет.
в данной ситуации вот в это
если сервера недалеко друг от друга, попробуйте dev-сервер использовать в production. если все будет ок, значит production не соответствует по софту или надежности железа.
Может, на том сервере антивирь какая-нибудь стоит... или процессы классика зависают по каким-то странным причинам.
когда в логах ничего нет, и все висит - это уже ненормально.
p.s. а вообще у меня уже давно недоверие к этому зоопарку линуксов...
верится с трудом.1) Системы на обоих серверах идентичны по набору софта.
если сервера недалеко друг от друга, попробуйте dev-сервер использовать в production. если все будет ок, значит production не соответствует по софту или надежности железа.
Может, на том сервере антивирь какая-нибудь стоит... или процессы классика зависают по каким-то странным причинам.
когда в логах ничего нет, и все висит - это уже ненормально.
p.s. а вообще у меня уже давно недоверие к этому зоопарку линуксов...
Тем не менее системы идентичны. В нашей организации процесс разработки стандартизирован. И все vps создаются из одного источника.
Процесс classic сервера через несколько минут работы подвисает и начинает съедать процессор целиком, приходится его убивать.
На production сервере крутятся, как я и говорил, еще несколько БД, причем с большей посещаемостью и гораздо большего размера ( >1Gb), с ними проблем нет. Т.е. неприятности именно с одной конкретно взятой базой, причем проявляются они именно в реальных условиях работы.
Процесс classic сервера через несколько минут работы подвисает и начинает съедать процессор целиком, приходится его убивать.
На production сервере крутятся, как я и говорил, еще несколько БД, причем с большей посещаемостью и гораздо большего размера ( >1Gb), с ними проблем нет. Т.е. неприятности именно с одной конкретно взятой базой, причем проявляются они именно в реальных условиях работы.
Попробовал слить структуру базы на production, и даже к "пустой" базе IBExpert не может приконнектиться. Все таже история: "Loading generators..." и прощай навсегда.
Казалось бы, напрашивается вывод - битая структура, что-то с RDB$XXXX отношениями, НО ПОЧЕМУ ЖЕ ТОГДА на разработческом эта база работает и тот же самый IBExpert не видит в ней изъянов?
Казалось бы, напрашивается вывод - битая структура, что-то с RDB$XXXX отношениями, НО ПОЧЕМУ ЖЕ ТОГДА на разработческом эта база работает и тот же самый IBExpert не видит в ней изъянов?
Не знаю честно говоря. А если совсем честно, то я не понял вопроса:)Merlin писал(а):Размер кеша в базе gfix-ом не прописан часом?
Процессов несколько, ведь на сервере не одна БД. Но именно тот процесс, который работает с моей многострадальной базой садится на шею процессору.WildSery писал(а):Правильно ли я понял - процесс классика только один? А откуда тогда "нагрузка" ?
Есть два варианта конца света:И ещё - тут я не вьехал - база там просто лежит, никто к ней не коннектится, а потом ты коннектишься экспертом - и бац! всё зависло?
1) Запускаю сайт на этой базе и при обращении к ней скриптом PHP процесс быстро занимает 1-е место в моем хитпараде top100, но не при первом же запросе, а при N-м, где N = 1..20 (pconnect не используется на сайте, вся работа на функциях ibase_connect).
2) IBExpert в принципе не может прочитать структуру базы, но в этом случае в top ничего не повисает, висит только IBExpert и каким-то образом лочится база (как я уже писал - нельзя даже shutdown сделать через gfix)
Да. Только эта. Остальные базы работают, на сколько им позволяет оставшийся 1% свободного времени процессора:)Виснет только эта база, остальные как ни в чём не бывало?
большое спасибо, обязательно обращусь к религии когда пойму что обречен.kdv писал(а):когда кажется, надо или креститься, или проверять базу gfix-ом.
Если вы посмотрите на мой первый пост, то увидете там упоминание о том, что проверки gfix-ом (-v -full) проходят без предупреждений. Сбор статистики - без проблем.
то есть, с FB работаете месяц-два?А если совсем честно, то я не понял вопроса
там написано что Вы делаете b/r и проверяете базу. Дальше идет "зависание", после чего я не вижу, что Вы делаете проверки.Если вы посмотрите на мой первый пост, то увидете
кстати. рекомендую в момент "зависания" получить инфу из fb_lock_print.