Помогите пожалуйста разобраться с нестабильной работой базы
Возникла такая ситуация (темы где рассматриваются похожие вопросы уже есть, но решения для себя я там не нашел.. 
):
есть сервер под виндой для web-приложения на нем стоит база Postgres-a, томкат, ява и все такое прочее для этого web-приложения. После очередного релиза который замудрили разрабы-яверы, БД начала ложится с нелепой периодичностью (в среднем раз в сутки), причем в то время когда нагрузки на нее либо вообще нет, либо она минимальна. Я вот прямо ощущаю 5-ой точкой моего организма, что дело дело в этом релизе, однако у остального коллектива мнение прямо противоположное - "База ложится - значит дело в базе. Починяй срочно Postgres, а то хана тебе суслик!!".
Из примечательных вещей: есть в этой базе таблица одна с полем bytea на 3 Гб и 40.000 строк (вся БД без этой таблицы - 400 Мб 
) и есть подозрение, что именно из-за нее все и рушится (хотя по идее не должно бы)
Вот что я успел по этому поводу предпринять:
bytea данные поубивал и забэкапил базу, обновить версию до PostgreSQL 9.2.4, восстановил дамп, загрузил обратно в таблицу с bytea данные. Процесс загрузки заключается в копировании данных из удаленного места и помещение их в текущую БД. Процесс получился длительный и в ходе него база периодически падала (каждые 4-5 часов).
Но как говорится: "Ни что не вечно под луной" и эта "нудятина" тоже закончилась.
И тогда настал черед "супер-логирования" вот что я решил оставить в настройках:
log_destination = 'stderr'
logging_collector = on
client_min_messages = 'notice'
log_min_messages = 'notice'
log_min_error_statement = 'notice'
log_error_verbosity = 'verbose'
log_line_prefix = '%t '
log_statement = 'all'
из настроек памяти:
shared_buffers = 64MB
work_mem = 2MB
maintenance_work_mem = 32MB
Результат - база опять лежит, а в логах - чистота и порядок..
Други, подскажите мне, как опытные джедаи подавану, в какую сторону можно еще покопать, может я не те логи настроил, или с памятью пожадничал????
(винда мне больше 1,5Гб оперативки выделить не может и на винте всего 10 Гб свободно)
Единственное, что еще могу добавить к этой "большой" таблице довольно часто идут обращения в основном - чтение, реже обновление и еще реже запись.
- Войдите или зарегистрируйтесь, чтобы добавлять комментарии
Так можно гадать до
Так можно гадать до посинения. Читайте логи, включайте подробное логгирование, если обычное не показывает ничего. Обычно проблемы всегда видны в логах.
Вполне согласен.. Гадать
Вполне согласен..
Гадать можно оччень долго, по-этому я и решил создать эту тему. В тех логах которые имею на текущий момент ничего необычного нет (хотя я их и "расширил")...
Я надеюсь, что кто-нибудь сможет подсказать в какую сторону рыть, какие еще логи стоит включить, может в настройках стоит что-то подправить..
Все настроечные параметры, которые я правил, я указал в описании темы.
А что за логи вы смотрите?
А что за логи вы смотрите? Смотрите ли вы до кучи Просмотр Событий в админке Винды? Может там чего полезное есть
ЕстественноВиндовозные логи
Естественно.
Виндовозные логи я тоже просматривал, там тоже ни чего интересного, какие-то мелкие ошибки служб (типа TrustedInstaller) и больше ни чего интересного..
Очень странно. Т.е. типа СУБД
Очень странно. Т.е. типа СУБД падает и никаких сообщений ни в одном из логов почему это происходит, я правильно понимаю?
Что-то есть
Какая-то информация в логах есть, но информативности в ней - 0, вот пример:
..................................................................................................................................................
2013-07-31 19:19:54 MSK ОТМЕТКА: 00000: процесс сервера (PID 5772) завершился с кодом выхода 0
2013-07-31 19:19:54 MSK ПОЛОЖЕНИЕ: LogChildExit, src\backend\postmaster\postmaster.c:2873
2013-07-31 19:19:54 MSK ОТМЕТКА: 00000: завершение всех остальных активных серверных процессов
2013-07-31 19:19:54 MSK ПОЛОЖЕНИЕ: HandleChildCrash, src\backend\postmaster\postmaster.c:2682
2013-07-31 19:19:54 MSK ПРЕДУПРЕЖДЕНИЕ: 57P00: закрытие подключения из-за краха другого серверного процесса
2013-07-31 19:19:54 MSK ПОДРОБНОСТИ: Управляющий процесс отдал команду этому серверному процессу откатить текущую транзакцию и завершиться, так как другой серверный процесс завершился аварийно и возможно разрушил разделяемую память.
2013-07-31 19:19:54 MSK ПОДСКАЗКА: Вы сможете переподключиться к базе данных и повторить вашу команду сию минуту.
2013-07-31 19:19:54 MSK ПОЛОЖЕНИЕ: quickdie, src\backend\tcop\postgres.c:2546
.............................................................................................................................................................
2013-07-31 19:19:54 MSK ПРЕДУПРЕЖДЕНИЕ: 57P00: закрытие подключения из-за краха другого серверного процесса
2013-07-31 19:19:54 MSK ПОДРОБНОСТИ: Управляющий процесс отдал команду этому серверному процессу откатить текущую транзакцию и завершиться, так как другой серверный процесс завершился аварийно и возможно разрушил разделяемую память.
2013-07-31 19:19:54 MSK ПОДСКАЗКА: Вы сможете переподключиться к базе данных и повторить вашу команду сию минуту.
2013-07-31 19:19:54 MSK ПОЛОЖЕНИЕ: quickdie, src\backend\tcop\postgres.c:2546
2013-07-31 19:19:54 MSK ОТМЕТКА: 00000: все серверные процессы завершены... переинициализация
2013-07-31 19:19:54 MSK ПОЛОЖЕНИЕ: PostmasterStateMachine, src\backend\postmaster\postmaster.c:3135
2013-07-31 19:20:04 MSK ВАЖНО: XX000: ранее созданный блок разделяемой памяти всё ещё используется
2013-07-31 19:20:04 MSK ПОДСКАЗКА: Если по-прежнему работают какие-то старые серверные процессы, снимите их.
2013-07-31 19:20:04 MSK ПОЛОЖЕНИЕ: PGSharedMemoryCreate, src\backend\port\win32_shmem.c:194
Угу, теперь несколько
Угу, теперь несколько понятней, т.е. СУБД падает не потому что какая-то ошибка в структуре или файлах СУБД, а потому что какая-то ошибка в коде. Правда это ещё фиговей, потому что найти такую ошибку не обладая знаниями разработчика невозможно.
Единственное, что я бы порекомендовал сделать:
1. Обновить СУБД до последней версии внутри релиза, т.е. если у вас 9.1.2 до до 9.1.последняя
2. Проверить память - чем чёрт не шутит - запустить на ночь какой-нибудь хороший тест памяти
Ещё что можно попробовать сделать, но это уже так, от отчаянья:
1. Сделать дамп БД
2. Удалить СУБД со всеми данными и поставить заново
3. Накатить дамп БД
Если будете это делать - потренируйтесь на кошечках вначале, чтобы не потерять базу
Практически все это я уже проделывал
Из простого я все уже попробовал.
1) Обновил СУБД до 9.2.4 (полностью удалил 9.1.2 и поставил 9.2.4)
2) Тест памяти запускать бессмысленно: сервак - виртуалка
3) Сделал дамп в виде SQL-комманд и потом воссатновил из него базу (при переходе с 9.1.2 на 9.2.4)
Я честно говоря грешу на яверов ибо работать с процедурами они отказались и пришлось им все в селектах писать, но все равно в логах постгреса я ни каких ошибок по селектам не нашел. Возможно, что, что-то (от явы исходящее) рубит по какой-то причине головной процесс, который тянет за собою все остальное.
Подскажите, как можно отследить жизненный цикл головного процесса, может можно для него какой-нибудь специальный лог включить..
На яверов можно грешить,
На яверов можно грешить, конечно, но тут судя по логами идёт падение СУБД. Такого в любом случае быть не должно! Я понимаю были бы какие-то ошибки внутри БД, были бы какие-то блокировки, таймауты - это всё решаемо, но если процесс валится нахрен, то тут явно что-то дело не чисто.
Попробуйте ещё отследить расход памяти в динамике, когда падение случается.
И ещё. Если сервер - виртуалка, может имеет смысл перейти на другую платформу для PostgreSQL? Я говорю о Linux.
Лог один для всех процессов, но если идёт обвал по коду - в логе разумеется ничего не будет.