Вводная:
Имеем железо с 4 Гб памяти, ОС - Debian Linux 3.0, ядро 2.4.31, на нем установлен IDS 7.31UC8.
Пользователей к IDS подключается много, нагрузка довольно большая, иногда - критичная по части дискового чтения (не будем тыкать пальцами в программеров с их неоптимизированными запросами :) ).
В данный момент имеем следующие параметры конфигурации, связанные с использованием Информиксом ОЗУ:
1.
2.
3.
4.
5.
6.
LOCKS 2000000
BUFFERS 400000
SHMBASE 0x50000000L
SHMVIRTSIZE 786432
SHMADD 32768
SHMTOTAL 0
в ядре увеличено на основании рекомендаций Installation Notes
SHMMAX 0xE0000000
(т.е. 3,5 Гб. - с лихвой)
Всего используется памяти Информиксом:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
# onstat -g seg
IBM Informix Dynamic Server Version 7.31.UD8 -- On-Line -- Up 06:11:22 -- 1739288 Kbytes
Segment Summary:
id key addr size ovhd class blkused blkfree
589103121 1381451777 50000000 974594048 34612 R* 118964 5
589135883 1381451778 8a172000 805306368 12932 V 17008 81296
589168652 1381451779 ba172000 1130496 664 M 132 6
Total: - - 1781030912 - - 136104 81307
Т.е. из 4Гб. ОЗУ в системе еще остается "неоприходованными" порядка 2 Гб. с хвостиком, которые, естественно, хотелось бы отдать Информиксу в распоряжение...
Теория гласит, что память Информиксом расходуется на 3 "порции":
Resident portion
Virtual portion
Message portion
Нас интересуют как наиболее "памятеемкие" - первые две.
Вижу по тому же "onstat -g seg", что в процессе эксплуатации Информикс дополнительных сегментов себе не берет, поэтому увеличивать исходный размер "Virtual portion" с помощью параметра SHMVIRTSIZE как бы и смысла нет - все равно достаточно уже.
Т.е. остается отдать ОЗУ Информиксу под BUFFERS, которые находятся в Resident portion.
Опять же в документации видим, что параметр BUFFERS может принимать значения (для Linux 32) от 100 до 1,843,200 (т.е. увеличивать еще есть куда).
А также рекомендуется выставлять его в пределах 20-25 % от объема системного ОЗУ - сейчас как раз и имеем 20%: 400000 * 2Кб = 800Мб.
Но я задался целью отдать еще немного памяти Информиксу под буфера как бы то ни было, и никаких гвоздей! :)
Вот в этом месте и начинаются проблемы.
Собсно процесс:
1) прямое увеличение
BUFFERS 500000 приводит к тому, что Информикс просто отказывается стартовать с ругательствами в логе:
1.
2.
3.
Segment locked: addr=0x50000000, size=1080778752
shmat: [ENOMEM][12]: out of available data space, check system MAXMEM
mt_shm_init: can't create virtual segment
Расследование содержимого исходников ядра показало, что MAXMEM определяется как-то хитро (с использованием переполнения long int, как мне подсказали матерые товарищи) и равняется и так 3,8Гб, поэтому беспокоиться нет причин (?)
ЗЫ. Кстати, прямое увеличение параметра SHMVIRTSIZE на треть (ради эксперимента) тоже приводит к нежеланию Информикса стартовать при вышеуказанных значениях остальных параметров.
2) после прочтения вот этого документа http://]www-1.ibm.com/support/docview.wss?uid=swg21215798# (похожая проблема) ради эксперимента удалось поднять SHMVIRTSIZE почти до 2 Гб. путем снижения параметра SHMBASE 0xB000000L.
Другими словами - Информиксу удалось отдать суммарно порядка 2,8Гб ОЗУ.
Правда, в логе при старте появляется ругательство вида (Информикс все равно стартует успешно, да и функционирует вроде тоже):
1.
2.
3.
4.
5.
6.
Contiguous shared memory segment allocation failed at 0xb000000.
Allocation retried at 0x42135000.
Check SHMBASE is consistent with the value in $INFORMIXDIR/etc/onconfig.std.
Consider using a different SHMBASE value in your ONCONFIG file.
If shared memory segments are not allocated in increasing address order,
memory block allocation performance may degrade.
А что же BUFFERS - спросите вы?
Хм, с SHMBASE 0xB000000L стартует при 500000 !!! но, увы, сразу же облом: при попытке выполнить команды onstat или onmode:
1.
2.
# onstat -g seg
onstat: Cannot attach to shared memory. errno = 22
Т.е. вышеописанное шаманство на необходимое увеличение BUFFERS все равно положительно не подействовало... :(
3) гугление и поиск на сайте IBM не дали подсказки к решению.
....
Чтобы не увеличивать и так получившийся огромным пост (пардон), скажу, что методом разнообразных махинаций с переменными LOCKS, SHMBASE, SHMVIRTSIZE, RESIDENT, SHMTOTAL добиться желаемого результата мне так и не удалось.
ВОПРОС: это вообще кому-то удавалось (имею ввиду ЗНАЧИТЕЛЬНОЕ увеличение BUFFERS по сравнению с "рабочими" 400 000) ?
(или может даже в FAQ уже прописали, но я был невнимателен?)
