Страница 1 из 1

Проблемы с базой после переноса на production сервер

Добавлено: 13 фев 2008, 16:42
noname
Ситуация выглядит так:

Есть база размер 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-а им далеко.

Если после прочтения описания проблемы вы потеряли ход моей мысли, то подытожу:
отлично функционирующая база начинает вести себя неадекватно при переносе на однотипный сервер, но работающий под нагрузкой.


Буду благодарен за любые советы, т.к. у меня версий нет.

Добавлено: 13 фев 2008, 16:48
kdv
в данной ситуации вот в это
1) Системы на обоих серверах идентичны по набору софта.
верится с трудом.
если сервера недалеко друг от друга, попробуйте dev-сервер использовать в production. если все будет ок, значит production не соответствует по софту или надежности железа.
Может, на том сервере антивирь какая-нибудь стоит... или процессы классика зависают по каким-то странным причинам.
когда в логах ничего нет, и все висит - это уже ненормально.

p.s. а вообще у меня уже давно недоверие к этому зоопарку линуксов...

Добавлено: 13 фев 2008, 17:00
noname
Тем не менее системы идентичны. В нашей организации процесс разработки стандартизирован. И все vps создаются из одного источника.

Процесс classic сервера через несколько минут работы подвисает и начинает съедать процессор целиком, приходится его убивать.

На production сервере крутятся, как я и говорил, еще несколько БД, причем с большей посещаемостью и гораздо большего размера ( >1Gb), с ними проблем нет. Т.е. неприятности именно с одной конкретно взятой базой, причем проявляются они именно в реальных условиях работы.

Добавлено: 13 фев 2008, 17:15
Attid
все равно фантастика.

попробуй на продакшен базу создать скриптом без данных, может что нового увидишь. а потом если все нормально будет тем же экспертом перельешь данные в два клика.

Добавлено: 13 фев 2008, 19:47
noname
Попробовал слить структуру базы на production, и даже к "пустой" базе IBExpert не может приконнектиться. Все таже история: "Loading generators..." и прощай навсегда.

Казалось бы, напрашивается вывод - битая структура, что-то с RDB$XXXX отношениями, НО ПОЧЕМУ ЖЕ ТОГДА на разработческом эта база работает и тот же самый IBExpert не видит в ней изъянов?

Добавлено: 13 фев 2008, 19:52
Merlin
Размер кеша в базе gfix-ом не прописан часом?

Добавлено: 13 фев 2008, 21:13
WildSery
Правильно ли я понял - процесс классика только один? А откуда тогда "нагрузка" ?
И ещё - тут я не вьехал - база там просто лежит, никто к ней не коннектится, а потом ты коннектишься экспертом - и бац! всё зависло?
Виснет только эта база, остальные как ни в чём не бывало?

Добавлено: 13 фев 2008, 22:29
kdv
напрашивается вывод - битая структура, что-то с RDB$XXXX отношениями
когда кажется, надо или креститься, или проверять базу gfix-ом.

Добавлено: 14 фев 2008, 11:14
noname
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) проходят без предупреждений. Сбор статистики - без проблем.

Добавлено: 14 фев 2008, 13:20
kdv
А если совсем честно, то я не понял вопроса
то есть, с FB работаете месяц-два?
Если вы посмотрите на мой первый пост, то увидете
там написано что Вы делаете b/r и проверяете базу. Дальше идет "зависание", после чего я не вижу, что Вы делаете проверки.

кстати. рекомендую в момент "зависания" получить инфу из fb_lock_print.