Доброго времени суток!
Хочу оптимизировать параметры настройки(работу) сервера
но прежде чем их менять прошу взглянуть, а также избавится от ошибки(ниже)
Прочитал много тем, прошу совета:
О себе:

Сервер: 2х2 Xeon 3.2 GHz, 6Gb RAM, array controller 256mb, 10 raid на SAS 72 Gb.
Linux 2.6.18-8.el5 (Red Hat 5)
IDS 10.00.UC5
32-бита :(

Нагрузка: в пиках около 320 пользователей.
onconfig:
#-------------------------------------------------------------------------#
ROOTSIZE 300000
PHYSFILE 299894

LOGFILES 1464
LOGSIZE 2048

IFX_EXTEND_ROLE 1

NETTYPE ipcshm,3,50,CPU
NETTYPE soctcp,4,100,NET
DEADLOCK_TIMEOUT 60
RESIDENT 1

MULTIPROCESSOR 1
NUMCPUVPS 4
NOAGE 1
AFF_SPROC 0
AFF_NPROCS 3

LOCKS 200000
NUMAIOVPS # пусто как расценивать?
PHYSBUFF 256
LOGBUFF 256
CLEANERS 12 # 32
SHMBASE 0x44000000
SHMVIRTSIZE 500000 # Хочу увеличить(1Gb) но прикинул что нельзя(ниже)
SHMADD 32768
EXTSHMADD 32768
SHMTOTAL 0
CKPTINTVL 30
TXTIMEOUT 0x12c
STACKSIZE 256

PC_HASHSIZE 62
PC_POOLSIZE 254

DYNAMIC_LOGS 2
LTXHWM 70
LTXEHWM 80

OFF_RECVRY_THREADS 10
ON_RECVRY_THREADS 1

CDR_EVALTHREADS 1,2
CDR_DSLOCKWAIT 5
CDR_QUEUEMEM 4096
CDR_NIFCOMPRESS 0
CDR_SERIAL 0,0
CDR_DBSPACE
CDR_QHDR_DBSPACE
CDR_QDATA_SBSPACE

RA_PAGES 98 # 56 много ли я выграю в памяти?
RA_THRESHOLD 94 # 54 на сколько эфф-но такое кол-во?

FILLFACTOR 90
MAX_PDQPRIORITY 100
DS_MAX_QUERIES 100
DS_TOTAL_MEMORY 80000
DS_MAX_SCANS 1048576
DS_NONPDQ_QUERY_MEM 128
DATASKIP off
OPTCOMPIND 2
DIRECTIVES 1
ONDBSPACEDOWN 2
OPCACHEMAX 0
HETERO_COMMIT 0
OPT_GOAL -1
ALLOW_NEWLINE 0
ONLIDX_MAXMEM 5120

BUFFERPOOL size=2K,buffers=512000,lrus=8,lru_min_dirty=1.000000,lru_max_dirty=5.000000
#BUFFERPOOL size=2K,buffers=512000,lrus=32,lru_min_dirty=5.000000,lru_max_dirty=10.000000

IFX_FOLDVIEW 0
SHMVIRT_ALLOCSEG 0.000000
EILSEQ_COMPAT_MODE 0
#-----------------------------------------------------------------------------------------------#

#пометил то что хочу изменить

сейчас загрузка минимальная(могу выложу в пиках):

первое что беспокоит:
-bash-3.1$ onstat -g seg

IBM Informix Dynamic Server Version 10.00.UC5 -- On-Line (Prim) -- Up 2 days 09:43:50 -- 2524032 Kbytes

Segment Summary:
id key addr size ovhd class blkused blkfree
720915 1381386259 ee5000 33554432 1672 V 8143 49
753684 1381386260 2ee5000 33554432 1672 V 5413 2779
1212450 1381386274 28000000 33554432 1672 V 2431 5761
1179681 1381386273 2a000000 33554432 1672 V 2290 5902
1146912 1381386272 2c000000 33554432 1672 V 1367 6825
1114143 1381386271 2e000000 33554432 1672 V 1010 7182
1081374 1381386270 30000000 33554432 1672 V 1107 7085
1048605 1381386269 32000000 33554432 1672 V 792 7400
1015836 1381386268 34000000 33554432 1672 V 1028 7164
983067 1381386267 36000000 33554432 1672 V 840 7352
950298 1381386266 38000000 33554432 1672 V 525 7667
917529 1381386265 3a000000 33554432 1672 V 684 7508
884760 1381386264 3c000000 33554432 1672 V 751 7441
851991 1381386263 3e000000 33554432 1672 V 1811 6381
819222 1381386262 40000000 33554432 1672 V 909 7283
786453 1381386261 42000000 33554432 1672 V 537 7655
65536 1381386241 44000000 1130921984 251404 R* 276100 4
98305 1381386242 87688000 512000000 16280 V 16202 108798
131074 1381386243 a5ed0000 540672 672 M 132 0
163843 1381386244 a5f54000 540672 672 M 132 0
196612 1381386245 a5fd8000 540672 672 M 132 0
229381 1381386246 a605c000 540672 672 M 132 0
327687 1381386247 a60e0000 33554432 1672 V 588 7604
360456 1381386248 a80e0000 33554432 1672 V 757 7435
393225 1381386249 aa0e0000 33554432 1672 V 618 7574
425994 1381386250 ac0e0000 33554432 1672 V 386 7806
458763 1381386251 ae0e0000 33554432 1672 V 866 7326
491532 1381386252 b00e0000 33554432 1672 V 447 7745
524301 1381386253 b20e0000 33554432 1672 V 313 7879
557070 1381386254 b40e0000 33554432 1672 V 119 8073
589839 1381386255 b60e0000 33554432 1672 V 106 8086
622608 1381386256 b80e0000 33554432 1672 V 118 8074
655377 1381386257 ba0e0000 33554432 1672 V 225 7967
688146 1381386258 bc0e0000 33554432 1672 V 145 8047
Total: - - 2584608768 - - 327156 303852

(* segment locked in memory)

1) Это нормально что при отсутсвии нагрузки на сервер у меня 1.2GB гуляет?
2) не дает резултатов команда onmode -F
3) RESIDENT 1 означает что виртульные сегменты полностью оперативе,
32 бита означает что у меня всего 4096 кб из которых еще от 500 - 800 надо для ОС,
смотрел в пиках значение тотал тоже только почти все блоки заняты(90-95%).
Могу ли я увеличить SHMVIRTSIZE до 1гб(1.5) и что я при это выйграю?
уменьшу количество сегментов которые выделяются и все?

onstat -l (начало)
Physical Logging
Buffer bufused bufsize numpages numwrits pages/io
P-1 3 128 2172930 23897 90.93
phybegin physize phypos phyused %used
3:53 149947 128779 3 0.00

Logical Logging
Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
L-2 0 128 28135583 1986996 597141 14.2 3.3
Subsystem numrecs Log Space used
OLDRSAM 28135583 3168772504

-bash-3.1$ onstat -g iov

AIO I/O vps:
class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup errors
msc 0 i 0.4 53237 0 0 0 50965 1.0 0
aio 0 i 357.3 51596641 49908640 1687998 0 49075302 1.1 0
aio 1 i 192.1 27749632 26559751 1189881 0 26431452 1.0 0
aio 2 i 112.1 16182627 15394714 787913 0 15279148 1.1 0
aio 3 i 70.6 10195691 9568448 627243 0 9279839 1.1 0
aio 4 i 49.0 7080515 6566687 513828 0 6147329 1.2 0
aio 5 i 38.0 5492896 5021668 471228 0 4560906 1.2 0
aio 6 i 31.3 4525979 4086556 439423 0 3607929 1.3 0
aio 7 i 26.6 3845437 3430661 414776 0 2947250 1.3 0
aio 8 i 23.2 3352705 2956253 396452 0 2477960 1.4 0
aio 9 i 20.9 3020856 2627755 393101 0 2140393 1.4 0
aio 10 i 19.0 2739306 2366225 373081 0 1870873 1.5 0
aio 11 i 17.0 2454268 2087461 366807 0 1625969 1.5 0
aio 12 i 15.5 2238704 1885401 353303 0 1421292 1.6 0
aio 13 i 14.2 2055795 1715726 340063 0 1247610 1.6 0
aio 14 i 13.2 1900776 1587791 312985 0 1104100 1.7 0
aio 15 i 12.4 1784616 1498654 285962 0 981364 1.8 0
pio 0 i 0.2 23923 0 23923 0 23914 1.0 0
lio 0 i 4.1 598153 0 598153 0 563984 1.1 0


-bash-3.1$ onstat -g iog

IBM Informix Dynamic Server Version 10.00.UC5 -- On-Line (Prim) -- Up 2 days 10:27:30 -- 2524032 Kbytes

AIO global info:
7 aio classes
11 open files
64 max global files

Еще раз повторюсь информация на момент отсутсвия нагрузки.
Любую необходимую информацию готов обеспечить.


И изюминка наш сервера

-bash-3.1$ onstat - (onmode...)
20:49:52 shmat: [22]: operating system error
20:49:52 Client could not attach server shared memory segment, use IFX_XFER_SHMBASE.
onstat: Cannot attach to shared memory. errno = 22

Бывает сразу команда срабатывае, иногда приходится раз от 1 до 5(10) раз повторять.

стразу отмечу:
-bash-3.1$ ipcs -m

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x52564801 65536 root 660 1130921984 30 locked
0x52564802 98305 root 660 512000000 30
0x52564803 131074 informix 666 540672 30
0x52564804 163843 root 666 540672 30
0x52564805 196612 root 666 540672 30
0x52564806 229381 root 666 540672 30
0x52564807 327687 informix 660 33554432 30
0x52564808 360456 informix 660 33554432 30
0x52564809 393225 informix 660 33554432 30
0x5256480a 425994 informix 660 33554432 30
0x5256480b 458763 informix 660 33554432 30
0x5256480c 491532 informix 660 33554432 30
0x5256480d 524301 informix 660 33554432 30
0x5256480e 557070 informix 660 33554432 30
0x5256480f 589839 informix 660 33554432 30
0x52564810 622608 informix 660 33554432 30
0x52564811 655377 informix 660 33554432 30
0x52564812 688146 informix 660 33554432 30
0x52564813 720915 informix 660 33554432 30
0x52564814 753684 informix 660 33554432 30
0x52564815 786453 informix 660 33554432 30
0x52564816 819222 informix 660 33554432 30
0x52564817 851991 informix 660 33554432 30
0x52564818 884760 informix 660 33554432 30
0x52564819 917529 informix 660 33554432 30
0x5256481a 950298 informix 660 33554432 30
0x5256481b 983067 informix 660 33554432 30
0x5256481c 1015836 informix 660 33554432 30
0x5256481d 1048605 informix 660 33554432 30
0x5256481e 1081374 informix 660 33554432 30
0x5256481f 1114143 informix 660 33554432 30
0x52564820 1146912 informix 660 33554432 30
0x52564821 1179681 informix 660 33554432 30
0x52564822 1212450 informix 660 33554432 30

Заранее благодарю за оказанное внимание.

При нормальной загрузке:
onstat -u
IBM Informix Dynamic Server Version 10.00.UC5 -- On-Line (Prim) -- Up 3 days 05:31:32 -- 2524032 Kbytes

Userthreads
address flags sessid user tty wait tout locks nreads nwrites
879e6018 ---P--D 1 informix - 0 0 0 1672 65893
879e6544 ---P--F 0 informix - 0 0 0 0 1007767
879e6a70 ---P--F 0 informix - 0 0 0 0 118402
879e6f9c ---P--F 0 informix - 0 0 0 0 193750
879e74c8 ---P--F 0 informix - 0 0 0 0 0
879e79f4 ---P--F 0 informix - 0 0 0 0 0
879e7f20 ---P--F 0 informix - 0 0 0 0 0
879e844c ---P--F 0 informix - 0 0 0 0 0
879e8978 ---P--F 0 informix - 0 0 0 0 0
879e8ea4 ---P--F 0 informix - 0 0 0 0 0
879e93d0 ---P--F 0 informix - 0 0 0 0 0
879e98fc ---P--F 0 informix - 0 0 0 0 0
879e9e28 ---P--F 0 informix - 0 0 0 0 0
879ea354 Y--P--- 14730 arvahiov TERMINAL 8a7f3fb0 0 2 225 2
879ea880 ---P--D 32 informix - 0 0 0 0 0
879eadac ---P--- 26 informix - 0 0 0 0 0
879eb2d8 ---P--B 27 informix - 0 0 0 8359136 256
879eb804 Y--P--D 30 informix - 88005e60 0 0 0 703
879ebd30 ---P--D 31 informix - 0 0 0 0 0
879ec25c Y--P--D 41 informix - 44085574 0 0 0 0
879ec788 ---P--D 39 informix - 0 0 0 0 0
.
b38f7950 Y--P--- 14438 xxx xxx1 9417a340 0 2 1153 74 #таких примерно 50-70%
..
95f06614 Y--P--- 12397 zzz zzz1 993cdd90 0 2 216204 756 #таких примерно 15-25%
...
87a09e2c Y--P--- 12257 yyy yyy1 97244248 0 2 470456 3563 #таких примерно 10-20%
....
95f00e28 Y--P--- 12758 qqq qqq1 aa742818 0 2 844378 10590 #таких примерно 5-7%
.....
291 active, 384 total, 302 maximum concurrent

#-------------------------------------------------------------------------------------------------#

-bash-3.1$ onstat -g seg
IBM Informix Dynamic Server Version 10.00.UC5 -- On-Line (Prim) -- Up 3 days 05:45:36 -- 2524032 Kbytes
Segment Summary:
id key addr size ovhd class blkused blkfree
720915 1381386259 ee5000 33554432 1672 V 8192 0
753684 1381386260 2ee5000 33554432 1672 V 8190 2
1212450 1381386274 28000000 33554432 1672 V 8191 1
1179681 1381386273 2a000000 33554432 1672 V 8186 6
1146912 1381386272 2c000000 33554432 1672 V 8191 1
1114143 1381386271 2e000000 33554432 1672 V 8188 4
1081374 1381386270 30000000 33554432 1672 V 8189 3
1048605 1381386269 32000000 33554432 1672 V 8190 2
1015836 1381386268 34000000 33554432 1672 V 8192 0
983067 1381386267 36000000 33554432 1672 V 8189 3
950298 1381386266 38000000 33554432 1672 V 8192 0
917529 1381386265 3a000000 33554432 1672 V 8191 1
884760 1381386264 3c000000 33554432 1672 V 8139 53
851991 1381386263 3e000000 33554432 1672 V 8088 104
819222 1381386262 40000000 33554432 1672 V 8023 169
786453 1381386261 42000000 33554432 1672 V 8129 63
65536 1381386241 44000000 1130921984 251404 R* 276100 4
98305 1381386242 87688000 512000000 16280 V 115972 9028
131074 1381386243 a5ed0000 540672 672 M 132 0
163843 1381386244 a5f54000 540672 672 M 132 0
196612 1381386245 a5fd8000 540672 672 M 132 0
229381 1381386246 a605c000 540672 672 M 132 0
327687 1381386247 a60e0000 33554432 1672 V 5268 2924
360456 1381386248 a80e0000 33554432 1672 V 3158 5034
393225 1381386249 aa0e0000 33554432 1672 V 3501 4691
425994 1381386250 ac0e0000 33554432 1672 V 2636 5556
458763 1381386251 ae0e0000 33554432 1672 V 200 7992
491532 1381386252 b00e0000 33554432 1672 V 157 8035
524301 1381386253 b20e0000 33554432 1672 V 208 7984
557070 1381386254 b40e0000 33554432 1672 V 108 8084
589839 1381386255 b60e0000 33554432 1672 V 103 8089
622608 1381386256 b80e0000 33554432 1672 V 117 8075
655377 1381386257 ba0e0000 33554432 1672 V 221 7971
688146 1381386258 bc0e0000 33554432 1672 V 143 8049
Total: - - 2584608768 - - 539080 91928
(* segment locked in memory)

#------------------------------------------------------------------------------------------------#
-bash-3.1$ onstat -g iov

IBM Informix Dynamic Server Version 10.00.UC5 -- On-Line (Prim) -- Up 3 days 05:47:23 -- 2524032 Kbytes

AIO I/O vps:
class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup errors
msc 0 i 0.7 15928 0 0 0 15397 1.0 0
aio 0 s 440.8 9770601 9555536 215065 0 9238094 1.1 0
aio 1 s 228.5 5064359 4872125 192234 0 4732634 1.1 0
aio 2 s 148.8 3298105 3143642 154463 0 3023752 1.1 0
aio 3 s 96.0 2127830 1997718 130112 0 1881035 1.1 0
aio 4 s 68.3 1514973 1394676 120297 0 1266042 1.2 0
aio 5 s 49.6 1100365 992205 108160 0 861047 1.3 0
aio 6 s 42.1 932471 833114 99357 0 688998 1.4 0
aio 7 s 35.2 779183 681927 97256 0 540723 1.4 0
aio 8 s 31.2 691115 600924 90191 0 458258 1.5 0
aio 9 i 28.3 627848 534192 93656 0 401023 1.6 0
aio 10 i 26.3 582615 496974 85641 0 364267 1.6 0
aio 11 i 24.6 544636 459976 84660 0 333018 1.6 0
aio 12 i 23.5 519797 436398 83399 0 310281 1.7 0
aio 13 i 22.2 491293 410978 80315 0 284326 1.7 0
aio 14 i 21.0 465147 390850 74297 0 264489 1.8 0
aio 15 i 19.6 433640 363678 69962 0 237946 1.8 0
pio 0 i 0.2 4289 0 4289 0 4288 1.0 0
lio 0 i 6.4 141936 0 141936 0 131732 1.1 0
#------------------------------------------------------------------------------------------------#
onstat -l

IBM Informix Dynamic Server Version 10.00.UC5 -- On-Line (Prim) -- Up 3 days 05:48:35 -- 2524032 Kbytes

Physical Logging
Buffer bufused bufsize numpages numwrits pages/io
P-1 95 128 334291 4297 77.80
phybegin physize phypos phyused %used
3:53 149947 124507 351 0.23

Logical Logging
Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
L-1 0 128 6602048 537143 142096 12.3 3.8
Subsystem numrecs Log Space used
OLDRSAM 6602048 891542256

address number flags uniqid begin size used %used
87a20a30 7 U-B---- 103038 2:53 1024 1024 100.00
87a20a78 13 U-B---- 103039 2:6197 1024 1024 100.00
.
.
.
#------------------------------------------------------------------------------------------------#

воот... что нибудь еще?

zaiets
При 6Гб памяти я б перешел на 64 бит. Линукс и информикс 32 бит для, как по мне не лучшая связка. Хотя все зависит от задач.


К сожалению разработчики нашего ПО на 100% не гарантируют ...(((пока)

zaiets
Дак здесь вас и просят установить IFX_XFER_SHMBASE.
Если б прочитали много тем - что-то б нашли на сайте производителя, там есть ссылки(нужно читать не только конференции).
Поставьте хотя бы в 0 и посмотрите.


release/ids_sqlr_docnotes_10.0.txt
...
1.3.10 IFX_XFER_SHMBASE Environment Variable

The IFX_XFER_SHMBASE environment variable provides an alternate base
address for a utility to attach shared memory segments.

>>-setenv--IFX_XFER_SHMBASE--address---------------------------><

address is a valid hexadecimal address.

When the database server allocates shared memory of given size, it could
allocate multiple operating-system (OS) shared-memory segments that are
contiguous. This means that a client utility that connects to the shared
memory must also attach all of the OS segments contiguously. The utility
could have some other shared objects (for example, the xbsa library in
the onbar utility) loaded at the address where the server has attached
shared memory segment. To work around this situation, you can use the
IFX_XFER_SHMBASE environment variable to specify a different base
address for the utility to attach the shared memory segments.

Setting IFX_XFER_SHMBASE is not an option for the onstat, onmode and
oncheck utilities, because these utilities must attach to the same
shared memory base as the oninit utility.

Не совсем разобрался что это..может кто подскажет?
Эксперементировать нет возможности :(.
На тестовых(незагруженых) серверах такой ошибки нет
Она начинается с момента когда Shered Memory > 2Gb...


vasilis
На эту тему очень рекомендую заглянуть в наш FAQ, где есть похожий топик.
Исследования IDS 10.00.TC4 на Win2003+SP1 (4GB) и некоторые рекомендации
http://www.sql.ru/faq/faq_topic.aspx?fid=982
И хотя там мои ииследования в Windows, но, надеюсь, что то же самое будет справедливо и для Linux.

Но у вас там эти утилиты перестают(полностью?) работать, у меня же ошибка, но утилиты срабатывают(раз 5..:, иногда сразу)

vasilis
zuwr
SHMBASE 0x44000000


Надеюсь, что это значение взято из рекомендаций ИБМ (release notes) ?


release/ids_machine_notes_10.00.txt
...
2. Location of Shared Memory

The ONCONFIG variable SHMBASE is set to the following:

SHMBASE 0x44000000L

- On Red Hat Enterprise Linux 3 the start address for shared libraries
is 0xb7600000 and memory address space is utilized downwards.

- SHMBASE can also be set to start above the shared library addresses.
When doing so, ensure that dynamically loaded shared libraries
do not collide with the shared memory segments.
The address space layout can be checked by the following command:
$ cat /proc/<pid of oninit process>/maps

Подозреваю что ошибка заключается в IFX_XFER_SHMBASE.



vasilis
Похоже, что у вас динамически добавилось слишком много журналов в результате какой-нибудь длинной транзакции. Просмотрите их распредиление по пространствам - возможно, что журналы расплодились по многим dbspaces и их оттуда надо убрать. Лучше выделить одно ДБ-пространство только для этих целей. да и такое кол-во вам вряд ли нужно - место зря пропадает.

С логическими журналами все впорядке(они постоянно сохраняются) все находятся в отдельном дбспейсе (он полностью ими занят 1464 штуки)

vasilis
DYNAMIC_LOGS 2

Я бы все таки этот параметр выключил - не люблю неконтролируемого размножения журналов. И если это не девелоперский сервер, а продакшен с устоявшимися запросами, то обязательно бы выключил, предварительно определив бы необходимый размер для самых больших транзакций .

1464 журнала, и они постоянно освобождаются, должно хватать?
вопрос есле LOGFILES 1464, будут добавлятся ли еще?
зы: отключу(1).

vasilis
zuwr
NUMAIOVPS # пусто как расценивать?


вы ничего не указали, вот и пусто :)
Выделение AIO VP идет по умолчанию, т.ч. особых проблем с этим нет
Кстати, вопрос Линуксоидам, а на этой ОС KAIO живет ?

По умолчанию...это выделяются по мере загружености?


vasilis
zuwr
RA_PAGES 98 # 56 много ли я выграю в памяти?
RA_THRESHOLD 94 # 54 на сколько эфф-но такое кол-во?


бытовало мнение, что сервер все равно обрезает максимальное значение до 32 (или 64) (Выбегалло ?)
Я бы рекомендовал поставить 64 и 48

А как отмониторть использование(эффективность) этой функции?
Как она влияеет на используюмую память?


vasilis
zuwr
DS_MAX_QUERIES 100
DS_TOTAL_MEMORY 80000


Это странная пропорция. Каждый PDQ запрос будет получать порции только по 800К.
Да и сотня разрешенных таких запросов положит любой сервак. Если они у вас в принципе используются.
Если да, то мои рекомендации
DS_MAX_QUERIES 10
DS_TOTAL_MEMORY 50000


Я так понял что при сложных запросах выделяются доп.ресурсы для их обработки: pdq
Но также запрос этой функции может быть связан с запросом, либо происходит самостоятельно..
Как отмониторить как они используются и в каком количестве?
Теоритически полная загрузка(100) будет хотеть 800мб(дополнительно?) памяти?


vasilis
zuwr
DS_NONPDQ_QUERY_MEM 128


А это нужно увеличить. Может существенно поднять производительность некоторых запросов с сортировкой. Например,
DS_NONPDQ_QUERY_MEM 1024


Тоесть PDQ и NONPDQ(те которые не могут использовать PDQ?) в сумме не болие DS_TOTAL_MEMORY(по памяти)?
DS_NONPDQ_QUERY_MEM и их в сумее с PDQ не болие чем DS_MAX_QUERIES(по количеству)?


vasilis
zuwr
BUFFERPOOL size=2K,buffers=512000,lrus=8,lru_min_dirty=1.000000,lru_max_dirty=5.000000


LRUS стоит по умолчанию, а это очень мало для такого кол-ва буферов.
Установите хотя бы 127 (или 255 если эта версия IDS позволяет такие значения)


release/ids_unix_relnotes_10.0.txt
...
1.9.2.7 BUFFERS, LRUS, LRU_MAX_DIRTY, and LRU_MIN_DIRTY Configuration
Parameters

The BUFFERS, LRUS, LRU_MAX_DIRTY, and LRU_MIN_DIRTY configuration
parameters are no longer used . Information that was specified with the
BUFFERS, LRUS, LRU_MAX_DIRTY, and LRU_MIN_DIRTY configuration parameters
prior to Version 10.0 is now specified using the BUFFERPOOL
configuration parameter or the onparams utility. Information you enter
using the BUFFERPOOL configuration parameter or onparams utility
supersedes any information previously specified with the deprecated
parameters.

Это вроде как и не правда...65536 1381386241 44000000 1130921984 251404 R* 276100 4
это же именно то что я указываю..
ограничения не нашол.
На чем выйграш в увеличении количества очередей:
Скорость поиска свободного(грязного) буфера?
Встречал еще что при может блокироваться вся очередь? или это ерунда?

[quot Чемберлен]
Увеличение количества очередей влияет на количество пользовательских потоков, которые могут одновременно искать свободный буфер. Пока пользоватьский поток ищет свободный буфер в очереди она заблокирована и не доступна дргуим потокам. С другой стороны, чем больше очередей, тем короче каждая из них и выше вероятность свободный буфер не найти...

При большом буферном кеше и сотнях пользователей очередей обычно должно быть побольше, например, 127.
[quot]
Ясно, а к насчет lru_min_dirty,lru_max_dirty это ведь относится к очередям или в целом к пулу буферов?(в смысле о вероятности не найти свободный буфер в очереди)

Чемберлен
С другой стороны, чем больше очередей, тем короче каждая из них и выше вероятность свободный буфер не найти...

Есле LRU_MAX_DIRTY установленно допустим 50, пользователь всегда найдет свободный буфер в очереди?