Общая память: сбои shmget: Никакое пространство не уехало на устройстве — как увеличить пределы?
Слишком много непредвиденных обстоятельств. Например, как диски настраиваются? Если журналы и данные совместно используют те же диски, то случайный ввод-вывод от областей данных разрушит трафик журнала, который является главным образом последовательным вводом-выводом и непропорционально затронут занятой рабочей нагрузкой произвольного доступа на тех же дисках.
Еще без некоторого понимания Вашей конфигурации я не могу действительно сказать, что могло бы вызывать проблему.
Например, 60MB/sec от RAID о прямо для RAID-5 с 4 дисками или RAID-10 с дорожками 64k и дисками 15k. Каждый диск считает одну дорожку 64k на оборот диска (приблизительно 250/секунд для диска 15k), который дает Вам 15MB/sec на диск.
Среднее время поиска для 15k диска составляет приблизительно 3 мс через целый диск. На главным образом непрерывном файле на 10 ГБ на объеме RAID с (говорят), что диски на 300 ГБ или на 146 ГБ и немного справки от кэша я видел, что 30MB/sec был разумным числом для дискового массива, настроенного, как описано выше. Это указало бы на усреднение чтения данных о каждых двух оборотах дисков.
Это - мысль первое, что пришло на ум для конфигурации, которую можно было бы обоснованно ожидать видеть на ML350. Однако я понятия не имею, соответствует ли это Вашей фактической конфигурации, таким образом, я не могу действительно прокомментировать, релевантны ли наблюдения в Вашем случае.
Оказывается, shmmni ограничен 32768 в ядре:
#define IPCMNI 32768 /* <= MAX_INT limit for ipc arrays (including sysctl changes) */
в файле ... версия ... / include / linux / ipc.h .
Это жесткое ограничение на количество сегментов совместно используемой памяти, если не считать перекомпиляции ядра.
Используйте ipcs -l , чтобы проверить действующие ограничения, и ipcs -a и ipcs -m , чтобы увидеть что используется, чтобы вы могли сравнить результат. Посмотрите на столбец nattch : есть ли сегменты без подключенных процессов, которые не были удалены при выходе из процесса (что обычно означает сбой программы)? ipcrm может очистить их, хотя, если это тестовая машина, перезагрузка выполняется быстрее (и гарантирует, что ваши изменения ограничений будут учтены).
Параметры ядра кажутся странными. В частности, shmall - это количество страниц, а не байтов, а 4 КБ - это размер страницы по умолчанию (запустите getconf PAGESIZE , чтобы проверить, что вы используете). Сколько у вас терабайт оперативной памяти?
Итак, вы говорите, что у вас есть около 32771 сегмента общей памяти, что также составляет около 32768 (или от 2 до 15), что предполагает, что 16-битное int со знаком является ограничивающим фактором. И какое ядро вы используете (так как у него будут свои ограничения)? Эти два могут быть связаны.
Поскольку shmget () выделяет новый сегмент разделяемой памяти, и вы, кажется, используете их много ( учитывая ваш limits.conf), возможно, вы используете слишком много сегментов разделяемой памяти? У меня нет большого опыта в вызове shmget () , но мне кажется, что количество возможных открытых файлов (1000000) больше, чем количество разрешенных сегментов разделяемой памяти (SHMMNI), что составляет 409600.