LINUX.ORG.RU
ФорумAdmin

[FreeBSD] Postgresql ERROR

 


1

0

Нужна консультация и помощь

при старте постгресса получаю

Apr  2 22:09:14 srv-web01 postgres[2056]: [1-1] FATAL:  could not create shared memory segment: Недопустимый аргумент
Apr  2 22:09:14 srv-web01 postgres[2056]: [1-2] DETAIL:  Failed system call was shmget(key=5432001, size=1101152256, 03600).
Apr  2 22:09:14 srv-web01 postgres[2056]: [1-3] HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. 
Apr  2 22:09:14 srv-web01 postgres[2056]: [1-4]  You can either reduce the request size or reconfigure the kernel with larger SHMMAX.  To reduce the request size (currently
Apr  2 22:09:14 srv-web01 postgres[2056]: [1-5]  1101152256 bytes), reduce PostgreSQL's shared_buffers parameter (currently 131072) and/or its max_connections parameter
Apr  2 22:09:14 srv-web01 postgres[2056]: [1-6]  (currently 43).
Apr  2 22:09:14 srv-web01 postgres[2056]: [1-7] 	If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising
Apr  2 22:09:14 srv-web01 postgres[2056]: [1-8]  the request size or reconfiguring SHMMIN is called for.
Apr  2 22:09:14 srv-web01 postgres[2056]: [1-9] 	The PostgreSQL documentation contains more information about shared memory configuration.

Вроде все написано, но я не понимаю о чем идет речь. Перечитал 20-30 ссылок в гугле, но так и не смог ни чего сделать, везде два варианта пересобрать ядро, изменить параметр. Но как и на какие значения не сказано.

cat postgresql.conf | grep shared_buffers
# also need to raise shared_buffers to support more connections.
shared_buffers = 1024MB			# min 128kB or max_connections*16kB
cat postgresql.conf | grep max_connection
max_connections = 40			# (change requires restart)

Скажу честно, я вообще не понимаю о чем идет речь, что это за параметры и за что они отвечают, поэтому неимею не малейшего предствления о том что произойдет если я их поменяю и какие они должны быть. На сервере 16Gb RAM.

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

Заранее спасибо.


Ответ на: комментарий от Tok

не я устанавливал сервер, по хорошему дебиан и нужно было ставить, но из за какихто сложностей поставили freeBSD. Обсуждать это бестолку :(

По поводу пересборки ядра, я понимаю если бы сразу посде установки она не запускалась, но я проверял все работало. Да и те люди кто базу перетаскивал тоже не дураки, думаю тоже проверяли. Пеняю на сбой сервера, но опять таки это только догадка.

Cupper
() автор топика
Ответ на: комментарий от Tok

Щас этап настройки сервера идет, на него щас 0 нагрузка идет, т.е. вообще ничего на нем почти не делается. Нет, переустанавливать ОСь думаю мне не позволят :) Сбой был ночью, сервер вообще стоял бездействовал, так что такой вариант тоже как сомнителен :(

Cupper
() автор топика

шаред_буфер в гиг? неслабо

syscat -a|grep shm покажите. ну и попробуйте все-таки шаред_буферы поменьше сделать - гиг для 40 коннектов, мягко говоря, многовато.

leave ★★★★★
()
Ответ на: комментарий от leave

Ну яж честно сказал что я мало представляю за что эти параметры отвечают, щас уже догадываться начинаю :)

max_connections это видимо максимальное количество одновременных запросов к БД %) или конектов, но я не понимаю как к БД конект можно делать ?) или под конектом имеется в виде подключение клиентской части Шреадер это видимо количество выделаюмой оперативки под все конекты ?)

sysctl -a | grep shm
kern.ipc.shm_allow_removed: 0
kern.ipc.shm_use_phys: 0
kern.ipc.shmall: 8192
kern.ipc.shmseg: 128
kern.ipc.shmmni: 192
kern.ipc.shmmin: 1
kern.ipc.shmmax: 33554432
kern.features.posix_shm: 1
Cupper
() автор топика
Ответ на: комментарий от leave

спасибо за ссылку, это частично прояснило ситуацию. Выделить гигабайт системой или псотгрес гигабайт запрашивает ?)

Cupper
() автор топика
Ответ на: комментарий от Cupper

постгрес просит гиг. ИМХО это ОЧЕНЬ много (хотя я, конечно, не знаю ваших потребностей). с моей колокольни посоветовал бы поставить shared_buffers = 128M, и соответственно изменить конфигурацию ядра (sysctl -w kern.ipc.shmmax=134217728)

leave ★★★★★
()
Ответ на: комментарий от leave

> хотя я, конечно, не знаю ваших потребностей

я к сожалению тоже не могу определить уровень нагрузки на сервер. Так что может просто прикинуть что и для скольки сойдет: вот например вы посоветовали shared_buffers = 128M, как это можно оценить с точки зрения объема БД и интенсивности ее использования? Просто цифры мне мало чего говорят.

Cupper
() автор топика
Ответ на: комментарий от Cupper

Выставио такие параметры системы kern.ipc.shm_use_phys=1 kern.ipc.shmall=32768 kern.ipc.semmap=256 kern.ipc.shmmax=134217728

Взял значения из стандартной рекомендации простгресса, но на весь инет ни слова не нашол о том для какого объема ОЗУ и нагрузки на БД эти значения являются оптимальными

Cupper
() автор топика
Ответ на: комментарий от Cupper
Объём задаётся параметром shared_buffers в файле postgresql.conf. Единица измерения параметра -- блоки величиной 8 кБ. По умолчанию значение параметра составляет 641, что соответствует 512 кБ памяти. Это весьма мало, и для полноценной работы значение параметра следует увеличить.
В качестве начальных значений можете попробовать следующие: 

Начните с 4 МБ (512) для рабочей станции 
Средний объём данных и 256-512 МБ доступной памяти: 16-32 МБ (2048-4096) 
Большой объём данных и 1-4 ГБ доступной памяти: 64-256 МБ (8192-32768)

Попробовал shared_buffers на 512Mb и 256Mb менять, все равно не старнует. Опускать ниже как то вообще нехочеться, сервер всетаки. Что нужно сделать чтобы пересобрать ядро с увеличением чего то там чтобы можно было shared_buffers не уменьшать ?

Cupper
() автор топика
Ответ на: комментарий от Cupper
Вот несколько примеров, полученных на личном опыте и при тестировании:
Laptop, Celeron processor, 384MB RAM, база данных 25MB: shared_buffers 12 MB
Athlon server, 1GB RAM, база данных поддержки принятия решений 10GB: 200 MB
Quad PIII server, 4GB RAM, 40GB, 150 соединений, "тяжелые" транзакции: 1 GB
Quad Xeon server, 8GB RAM, 200GB, 300 соединений, "тяжелые" транзакции: 2 GB

Гы, сервер который я настраиваю в 3 раза мощьней самого сильного из этих, а shared_buffers как на рабочую станцию выставлен, и то не фурычит :(

Cupper
() автор топика
Ответ на: комментарий от Cupper

Не понимаю че не так :(

sysctl -a | grep shm
kern.ipc.shm_allow_removed: 0
kern.ipc.shm_use_phys: 1
kern.ipc.shmall: 32768
kern.ipc.shmseg: 128
kern.ipc.shmmni: 192
kern.ipc.shmmin: 1
kern.ipc.shmmax: 1073741824 (1024*1024*1024)
kern.features.posix_shm: 1
shared_buffers = 256MB
Apr  3 18:42:13 srv-web01 postgres[1424]: [1-1] FATAL:  could not create shared memory segment: Невозможно выделить память
Apr  3 18:42:13 srv-web01 postgres[1424]: [1-2] DETAIL:  Failed system call was shmget(key=5432001, size=277757952, 03600).
Apr  3 18:42:13 srv-web01 postgres[1424]: [1-3] HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space.
Apr  3 18:42:13 srv-web01 postgres[1424]: [1-4]  To reduce the request size (currently 277757952 bytes), reduce PostgreSQL's shared_buffers parameter (currently 32768) and/or
Apr  3 18:42:13 srv-web01 postgres[1424]: [1-5]  its max_connections parameter (currently 43).
Apr  3 18:42:13 srv-web01 postgres[1424]: [1-6] 	The PostgreSQL documentation contains more information about shared memory configuration.
Apr  3 18:42:21 srv-web01 ntpd[1372]: kernel time sync status change 2001

Такое чувство что увеличение kern.ipc.shmmax вообще ничего не дает, или же не в ней проблема.

Cupper
() автор топика
Ответ на: комментарий от Cupper

Спасибо всем кто хоть както помог, спустя кучу часов я осознал все «соль».

Все делал почти правильно, нужно знать следующее Параметр shared_buffers должен быть меньше kern.ipc.shmmax, при этом shared_buffers может задаваться например как в моем случае сразу в Mb, таким образом

shared_buffers <= kern.ipc.shmmax / 1024 / 1024

Но это не все :) от kern.ipc.shmmax небудет толку если не задан правильно kern.ipc.shmall который определяет размер всей разделяемой памяти, стандартно равен kern.ipc.shmmax / PAGE_SIZE

PAGE_SIZE обычно равер 4096 байт.

Таким образом для того чтобы задать в postgresql shared_buffers=512Мb Получаем:

kern.ipc.shmall: 262144
kern.ipc.shmmax: 1073741824 (при таком значении shared_buffers можно задавать вплоть до 1024Mb, 1073741824/1024/1024 = 1024)

Надеюсь кому то это поможет, и спасет его выходной.

Cupper
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.