Поставил на FreeBSD 4.7-RELEASE-p7 PostgreSQL 7.3.2 (из свежиших портов), создал базу, конфиг оставил поумолчанию, только разрешил соединятся по TCP с адресов из локальной сети.Так вот, БД работает какое-то время, но иногда у SQL-сервера случается желание перестать работать, он просто берет и сам выгружается с записью в логах "fast shutdown request". Выгружается он в тот момент когда к нему нет никаких запросов, то есть в те моменты, когда он ничем не занят.
Глюк этот тормознутый, и проявляется примерно с периодичностью через каждые 3-5 дней. Причем когда это случается, начинаю его перезапускать (/usr/local/etc/010.pgsql.sh start), а он работает минут 5-10 и снова "fast shutdown request", Глюк исчезает только после полной перезагрузки мышины - reboot :( После чего можно спокойно жить пару другую дней.
Никто не сталкивался с такой проблемой? Как бороться с этой напастью?
Покопался в исходниках PostgreSQL, выяснил, что "fast shutdown request" выполняется только если процесс получает сигнал INT. Но почему он начинает его получать мне непонятно. К машине кроме меня никто не имеет доступ, получается, что сигнал INT, кроме ядра и меня послать SQL-серверу никто не может, раз я не посылал, остается ядро. Но почему??? Подскажите кто-нить, он меня уже замучил своими произвольными отрубонами. :(((
Вот лог с полным журналированием одного такого случая, из которого видно что в 13:17:22 SQL-сервер отработал последний запрос, а в 13:20:27 начал заниматься какой-то сборкой "дохлых" процессов после чего сдулся выполнив "fast shutdown request".
...
2003-03-14 13:17:22 [57893] LOG: statement: SELECT *
FROM d_news
2003-03-14 13:17:22 [57893] LOG: запрос: SELECT *
FROM d_news
2003-03-14 13:17:22 [57893] DEBUG: ProcessQuery
2003-03-14 13:17:22 [57893] LOG: statement: SELECT *
FROM d_news
2003-03-14 13:17:22 [57893] DEBUG: CommitTransactionCommand
2003-03-14 13:17:22 [57893] LOG: statement: SELECT *
FROM d_news
2003-03-14 13:17:22 [57893] LOG: duration: 0.002038 sec
2003-03-14 13:17:22 [57893] DEBUG: proc_exit(0)
2003-03-14 13:17:22 [57893] DEBUG: shmem_exit(0)
2003-03-14 13:17:22 [57893] DEBUG: exit(0)
2003-03-14 13:17:22 [57190] DEBUG: reaping dead processes
2003-03-14 13:17:22 [57190] DEBUG: child process (pid 57893) exited with exit code 0
2003-03-14 13:20:27 [57944] DEBUG: proc_exit(0)
2003-03-14 13:20:27 [57944] DEBUG: shmem_exit(0)
2003-03-14 13:20:27 [57944] DEBUG: exit(0)
2003-03-14 13:20:27 [57190] DEBUG: reaping dead processes
2003-03-14 13:20:27 [57190] DEBUG: child process (pid 57944) exited with exit code 0
2003-03-14 13:25:27 [58003] DEBUG: proc_exit(0)
2003-03-14 13:25:27 [58003] DEBUG: shmem_exit(0)
2003-03-14 13:25:27 [58003] DEBUG: exit(0)
2003-03-14 13:25:27 [57190] DEBUG: reaping dead processes
2003-03-14 13:25:27 [57190] DEBUG: child process (pid 58003) exited with exit code 0
2003-03-14 13:30:27 [58076] DEBUG: proc_exit(0)
2003-03-14 13:30:27 [58076] DEBUG: shmem_exit(0)
2003-03-14 13:30:27 [58076] DEBUG: exit(0)
2003-03-14 13:30:27 [57190] DEBUG: reaping dead processes
2003-03-14 13:30:27 [57190] DEBUG: child process (pid 58076) exited with exit code 0
2003-03-14 13:35:27 [58190] DEBUG: proc_exit(0)
2003-03-14 13:35:27 [58190] DEBUG: shmem_exit(0)
2003-03-14 13:35:27 [58190] DEBUG: exit(0)
2003-03-14 13:35:27 [57190] DEBUG: reaping dead processes
2003-03-14 13:35:27 [57190] DEBUG: child process (pid 58190) exited with exit code 0
2003-03-14 13:39:08 [57190] DEBUG: pmdie 2
2003-03-14 13:39:08 [57190] LOG: fast shutdown request
2003-03-14 13:39:08 [58234] LOG: отключение в процессе
2003-03-14 13:39:09 [57190] DEBUG: pmdie 2
2003-03-14 13:39:09 [57190] DEBUG: pmdie 2
2003-03-14 13:39:09 [57190] DEBUG: pmdie 2
2003-03-14 13:39:10 [58234] LOG: система отключена
2003-03-14 13:39:10 [58234] DEBUG: proc_exit(0)
2003-03-14 13:39:10 [58234] DEBUG: shmem_exit(0)
2003-03-14 13:39:10 [58234] DEBUG: exit(0)
2003-03-14 13:39:10 [57190] DEBUG: reaping dead processes
2003-03-14 13:39:10 [57190] DEBUG: proc_exit(0)
2003-03-14 13:39:10 [57190] DEBUG: shmem_exit(0)
2003-03-14 13:39:10 [57190] DEBUG: exit(0)
Ядро пересобрано, семафоров и шаред памяти более чем достатоночно:
# sysctl -a | grep kern\.ipc\.s
kern.ipc.sockbuf_waste_factor: 8
kern.ipc.somaxconn: 1024
kern.ipc.semmap: 256
kern.ipc.semmni: 256
kern.ipc.semmns: 512
kern.ipc.semmnu: 256
kern.ipc.semmsl: 64
kern.ipc.semopm: 100
kern.ipc.semume: 10
kern.ipc.semusz: 92
kern.ipc.semvmx: 32767
kern.ipc.semaem: 16384
kern.ipc.shmmax: 67108864
kern.ipc.shmmin: 1
kern.ipc.shmmni: 128
kern.ipc.shmseg: 256
kern.ipc.shmall: 16384
kern.ipc.shm_use_phys: 0Подскажите пожалуйста кто чего знает!!!
У меня та же FreeBSD, но postgresql не из портов, а собран из родных исходников. Никаких проблем не наблюдается. Попробуй пересобрать, загрузи ядро с "maxusers 512">kern.ipc.sockbuf_waste_factor: 8
...здесь все ok.
>У меня та же FreeBSD, но postgresql не из портов, а собран из родных
>исходников. Никаких проблем не наблюдается. Попробуй пересобрать,
>загрузи ядро с "maxusers 512"maxuser равно 512, А вот особого смысла в пересборке самому не вижу. Какая разница самому собирать или из порта? Как-то особенно код компилится который руками собираешь?
>
>>kern.ipc.sockbuf_waste_factor: 8
>...
>
>здесь все ok.
>maxuser равно 512, А вот особого смысла в пересборке самому не вижу.
>Какая разница самому собирать или из порта? Как-то особенно код компилится
>который руками собираешь?В портах несколько дополнительных патчей, один из которых достаточно подозрителен и как раз патчит что-то связанное с прерываниями.
>>maxuser равно 512, А вот особого смысла в пересборке самому не вижу.
>>Какая разница самому собирать или из порта? Как-то особенно код компилится
>>который руками собираешь?
>
>В портах несколько дополнительных патчей, один из которых достаточно подозрителен и как
>раз патчит что-то связанное с прерываниями.В исходники лезут всего два.
1.
patch-src::backend::commands::async.c
Add a patch fix a long standing bug in PostgreSQL with LISTEN/NOTIFY
queues and shutting down the database. Not bumping port revision, but if
you are having problems related to the above, update as necessary.Submitted by: Larry Rosenman <ler@lerctr.org>
2.
patch-src::backend::utils::adt::numutils.c
Add patch for a fix for braindead applications that were depending on
atoi('') (ex: RT and Horde). While I'm here, de-"pkg-comment"-ify. Port
revision bump.Submitted by: Larry Rosenman <ler@lerctr.org>
Approved by: maintainerПо вашему мешает первый?