|
|
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
vasilisК сожалению, концовку вывода запроса ты обрезал. тас как раз и хотел посмотреть загрузку процессоров. снова обнулил статистику сегодня утром. Версия полная, двухстраничная! $) ______________ ===== CPU Profile ==== hostname xxxxx boot_time 2004-10-10 13:49:03 _running_time 114 01:05:57 zero_profile_time 2005-02-01 08:49:16 statistic_time 0 06:05:44 ______________ ------------------------------- __________ --Onconfig Effective-- num_cpuvps 2 multiprocessor 1 ______________ ------------------------------- __________ -- Stamp activity from boot -- boot_stamp 655519076 current_stamp 975416912 _stamp_update 319897836 _activity_psec 32.4534 __________ -- Processor Stat Time -- usercpu_time 6177.22 syscpu_time 94.74 _all_cpu_time 6271.96 _user2sys_ratio 98.49 _ids_cputime_ratio 28.58 ______________ ------------------------------- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 14:57 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
genix _user2sys_ratio 98.49 _ids_cputime_ratio 28.58 Вот теперь все нормально :) Видно, что процы в среднем загружены только на треть и запас мощности для обработки пиковых загрузок имеется. Да и соотношение user и sys, которое меня смущало, теперь выглядит стандартно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 15:03 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
vasilis _user2sys_ratio 98.49 Да и соотношение user и sys, которое меня смущало, теперь выглядит стандартно. Оно и раньше, оказывается, было таким же (я просто делил ранее "на глазок", а сейчас, с помощью калькулятора, убедился в другом :) Хотя посмотрел сейчас на несколько нагруженных систем - все таки соотношение меньше, на уровне 85-90, но не 98,5... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 15:12 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Коды флага для 1-й позиции: (причина ожидания) B waiting on a buffer Подскажите плиз, как бороться с данным явлением? по onstat -u обнаружилась сессия: 37901d08 B--PR-- 34322 akimov GLOBALOD 10cf50f0 0 2 103349636 0 почему происходит такое и как избежать в будущем? памяти 4 Гб, но похоже что она используется не полностью: просматривая status tool в onperf вижу: onperf Shared memory size: 28.20 Мб Collector virtual memory size: 129.59 Мб нормально ли это для 4Гб оператвки на сервере? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 17:06 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
genix Подскажите плиз, как бороться с данным явлением? по onstat -u обнаружилась сессия: 37901d08 B--PR-- 34322 akimov GLOBALOD 10cf50f0 0 2 103349636 0 почему происходит такое и как избежать в будущем? В принципе это не страшно, обращение к диску будет всегда :), но от ДБА требуется минимизировать эти обращения, использовав максимум доступного ОЗУ под буферизацию. Оценить уровень кеширования можно посмотрев onstat -p genix памяти 4 Гб, но похоже что она используется не полностью: просматривая status tool в onperf вижу: Памяти иформикс использует столько, сколько ему разрешили настройками в onconfig. Покажи вывод onstat -g seg ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 17:22 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
genix Журавлев Денис Коды флага для 1-й позиции: (причина ожидания) B waiting on a buffer Подскажите плиз, как бороться с данным явлением? по onstat -u обнаружилась сессия: 37901d08 B--PR-- 34322 akimov GLOBALOD 10cf50f0 0 2 103349636 0 почему происходит такое и как избежать в будущем? памяти 4 Гб, но похоже что она используется не полностью: просматривая status tool в onperf вижу: onperf Shared memory size: 28.20 Мб Collector virtual memory size: 129.59 Мб Неплохо бы наконец узнать платформу, версию сервера, и увидеть onconfig файл. Для 32разрядных версий Информикс никогда не сможет использовать 4Г пямяти - в зависимости от платформы мах будет в районе 2.75Г. А ожидать буфера акимов может по банальной причине - в этот самый буфер кто-то пишет. нормально ли это для 4Гб оператвки на сервере? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 17:30 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
Оценить уровень кеширования можно посмотрев onstat -p порядка 79% на чтение и 95 на запись А вот параметр bufwaits неуклонно растет и уже достиг цифры 5443658 (статистику обнулял утром) Покажи вывод onstat -g seg $ onstat -u && onstat -g ses IBM Informix Dynamic Server Version 9.40.UC5 -- On-Line -- Up 77 days 21:32: 48 -- 809164 Kbytes Userthreads address flags sessid user tty wait tout locks nreads nwrites 378fe018 ---P--D 1 root - 0 0 0 269 4244 378fe630 ---P--F 0 root - 0 0 0 0 371942 378fec48 ---P--F 0 root - 0 0 0 0 0 378ff260 ---P--- 9 root - 0 0 0 0 148 379004a8 ---P--D 12 root - 0 0 0 0 0 37900ac0 Y--P--D 19 root - 1008ad28 0 0 0 0 379010d8 ---P--B 16 root - 0 0 0 340 0 37901d08 ---PR-- 34322 akimov GLOBALOD 0 0 2 152408420 660 37903b80 B--PR-- 34362 db722079 GLOBALOD 10d5f0a0 0 3 201582 50957 37904198 Y--P--- 34332 db722092 GLOBALOD 38491a38 0 2 3206 0 379047b0 Y--P--- 34326 techno CENTER1 38401bf8 0 2 232 0 37904dc8 Y--P--- 34349 db722092 GLOBALOD 385098b0 0 2 460 0 379053e0 Y--P--- 34208 abanshin 6 385ad568 0 2 13214 6832 37906628 Y--P--- 34325 techno CENTER1 388155c8 0 1 10 0 14 active, 128 total, 19 maximum concurrent IBM Informix Dynamic Server Version 9.40.UC5 -- On-Line -- Up 77 days 21:32: 48 -- 809164 Kbytes session #RSAM total used dyna mic id user tty pid hostname threads memory memory expl ain 34370 informix - 0 - 0 12288 7904 off 34362 db722079 GLOBALOD 968 globalod 1 114688 105576 off 34349 db722092 GLOBALOD 968 globalod 1 69632 46440 off 34332 db722092 GLOBALOD 968 globalod 1 65536 41800 off 34326 techno CENTER1 1008 center1 1 53248 39040 off 34325 techno CENTER1 1008 center1 1 40960 31976 off 34322 akimov GLOBALOD 968 globalod 1 69632 59424 off 34208 abanshin 6 17222 bank1 1 184320 166840 off 7 informix - 0 - 0 12288 9120 off 6 informix - 0 - 0 12288 7904 off 5 informix - 0 - 0 12288 7904 off 4 informix - 0 - 0 12288 9120 off 3 informix - 0 - 0 12288 7904 off 2 informix - 0 - 0 12288 7904 off P.$.: речь идет уже о другом (втором) сервере, на котором вертится 9.40.UC5 P.P.$.: планирую перетащить и 7.31 на 9.40, есть ли какие подводные камни? на что обратить внимание в первую очередь? базы хочу перетаскивать dbimport'ом/dbexport ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 17:40 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
genix порядка 79% на чтение и 95 на запись [quot ] оригинально, может все таки и нам покажешь onstat -p там еще много всего интресного. [quot genix] $ onstat -u && onstat -g ses Покажи вывод onstat -g seg !!!! --SEG-- genix P.$.: речь идет уже о другом (втором) сервере, на котором вертится 9.40.UC5 Завел бы отдельную ветку, запутаешь всех сейчас. А пользователей всегда 8 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 17:51 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
Покажи вывод onstat -g seg !!!! --SEG-- Йо, блин. Сам удивляюсь своей невнимательности. Правда пользователи уже все свалили, вот что осталось на "пустой" базе. Подскажите, на какие аспекты смотреть? $ onstat -g seg IBM Informix Dynamic Server Version 9.40.UC5 -- On-Line -- Up 77 days 22:52:00 -- 809164 Kbytes Segment Summary: id key addr size ovhd class blkused blkfree 2326528 1381386241 10000000 660570112 234980 R* 161247 25 2981908 1381386261 375f8000 67108864 2688 V 6876 9508 3047446 1381386263 3b5f8000 241664 648 M 38 21 3080215 1381386264 3b633000 33554432 1664 V 29 8163 3112984 1381386265 3d633000 33554432 1664 V 1 8191 3145753 1381386266 42135000 33554432 1664 V 2 8190 Total: - - 828583936 - - 168193 34098 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2005, 18:56 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
genix Подскажите, на какие аспекты смотреть? $ onstat -g seg IBM Informix Dynamic Server Version 9.40.UC5 -- On-Line -- Up 77 days 22:52:00 -- 809164 Kbytes Segment Summary: id key addr size ovhd class blkused blkfree 2326528 1381386241 10000000 660570112 234980 R* 161247 25 2981908 1381386261 375f8000 67108864 2688 V 6876 9508 3047446 1381386263 3b5f8000 241664 648 M 38 21 3080215 1381386264 3b633000 33554432 1664 V 29 8163 3112984 1381386265 3d633000 33554432 1664 V 1 8191 3145753 1381386266 42135000 33554432 1664 V 2 8190 Total: - - 828583936 - - 168193 34098 Здесь отображается сколько и как информикс использует память. Строка с классом R показывает что под буферизацию дисков выделено 630 мгб. Хватает этого или нет можно понять по onstat -p (может все таки покажешь его? и onconfig тоже onstat -c и все остальное (см.faq)). Вторая строка (класс V) говорит что первоначально был выделен виртуальный сегмент 64 мгб, но видимо его не хватило и информикс прихватил еще 3 по 32 мгб, если системе постоянно требуется 160 мгб в виртуальном сегменте желательно сразу так и настроить. А вообще RTFM. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2005, 16:50 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Здесь отображается сколько и как информикс использует память. Строка с классом R показывает что под буферизацию дисков выделено 630 мгб. Хватает этого или нет можно понять по onstat -p (может все таки покажешь его? и onconfig тоже onstat -c и все остальное (см.faq)). Вторая строка (класс V) говорит что первоначально был выделен виртуальный сегмент 64 мгб, но видимо его не хватило и информикс прихватил еще 3 по 32 мгб, если системе постоянно требуется 160 мгб в виртуальном сегменте желательно сразу так и настроить. А вообще RTFM. "onstat -c | egrep -v '^#|^$'" ROOTNAME rootdbs # Root dbspace name ROOTPATH /dev/sdd1 # Path for device containing root dbspace ROOTOFFSET 0 # Offset of root dbspace into device (Kbytes) ROOTSIZE 10241406 # Size of root dbspace (Kbytes) MIRROR 0 # Mirroring flag (Yes = 1, No = 0) MIRRORPATH # Path for device containing mirrored root MIRROROFFSET 0 # Offset into mirrored device (Kbytes) PHYSDBS rootdbs # Location (dbspace) of physical log PHYSFILE 200000 # Physical log file size (Kbytes) LOGFILES 20 # Number of logical log files LOGSIZE 100000 # Logical log size (Kbytes) MSGPATH /opt/informix/online.log # System message log file path CONSOLE /dev/console # System console message path ALARMPROGRAM /opt/informix/etc/alarmprogram.sh # Alarm program path TBLSPACE_STATS 1 # Maintain tblspace statistics TAPEDEV /dev/null # Tape device path TAPEBLK 32 # Tape block size (Kbytes) TAPESIZE 10240 # Maximum amount of data to put on tape (Kbytes) LTAPEDEV /dev/null # Log tape device path LTAPEBLK 32 # Log tape block size (Kbytes) LTAPESIZE 10240 # Max amount of data to put on log tape (Kbytes) STAGEBLOB # Informix Dynamic Server staging area SERVERNUM 0 # Unique id corresponding to a OnLine instance DBSERVERNAME bank1 # Name of default database server DBSERVERALIASES # List of alternate dbservernames NETTYPE soctcp,1,10,NET # Configure poll thread(s) for nettype NETTYPE ipcshm,1,10,CPU # Configure poll thread(s) for nettype DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env. RESIDENT 1 # Forced residency flag (Yes = 1, No = 0) MULTIPROCESSOR 1 # 0 for single-processor, 1 for multi-processor NUMCPUVPS 2 # Number of user (cpu) vps SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to one NOAGE 0 # Process aging AFF_SPROC 0 # Affinity start processor AFF_NPROCS 4 # Affinity number of processors LOCKS 10000 # Maximum number of locks BUFFERS 300000 # Maximum number of shared buffers NUMAIOVPS 2 # Number of IO vps PHYSBUFF 512 # Physical log buffer size (Kbytes) LOGBUFF 512 # Logical log buffer size (Kbytes) CLEANERS 2 # Number of buffer cleaner processes SHMBASE 0x10000000 # Shared memory base address SHMVIRTSIZE 65535 # initial virtual shared memory segment size SHMADD 32768 # Size of new shared memory segments (Kbytes) SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited CKPTINTVL 300 # Check point interval (in sec) LRUS 127 # Number of LRU queues LRU_MAX_DIRTY 40.000000 # LRU percent dirty begin cleaning limit LRU_MIN_DIRTY 35.000000 # LRU percent dirty end cleaning limit TXTIMEOUT 0x12c # Transaction timeout (in sec) STACKSIZE 32 # Stack size (Kbytes) DYNAMIC_LOGS 2 LTXHWM 70 LTXEHWM 80 OFF_RECVRY_THREADS 10 # Default number of offline worker threads ON_RECVRY_THREADS 1 # Default number of online worker threads DRINTERVAL 30 # DR max time between DR buffer flushes (in sec) DRTIMEOUT 30 # DR network timeout (in sec) DRLOSTFOUND /opt/informix/etc/dr.lostfound # DR lost+found file path CDR_EVALTHREADS 1,2 # evaluator threads (per-cpu-vp,additional) CDR_DSLOCKWAIT 5 # DS lockwait timeout (seconds) CDR_QUEUEMEM 4096 # Maximum amount of memory for any CDR queue (Kbytes) CDR_NIFCOMPRESS 0 # Link level compression (-1 never, 0 none, 9 max) CDR_SERIAL 0,0 # Serial Column Sequence CDR_DBSPACE # dbspace for syscdr database CDR_QHDR_DBSPACE # CDR queue dbspace (default same as catalog) CDR_QDATA_SBSPACE # List of CDR queue smart blob spaces CDR_MAX_DYNAMIC_LOGS 0 # Dynamic log addition disabled by default BAR_ACT_LOG /opt/informix/bar_act.log # ON-Bar Log file - not in /tmp please BAR_DEBUG_LOG /opt/informix/bar_dbug.log BAR_MAX_BACKUP 0 BAR_RETRY 1 BAR_NB_XPORT_COUNT 10 BAR_XFER_BUF_SIZE 31 RESTARTABLE_RESTORE on BAR_PROGRESS_FREQ 0 ISM_DATA_POOL ISMData ISM_LOG_POOL ISMLogs RA_PAGES 100 # Number of pages to attempt to read ahead RA_THRESHOLD # Number of pages left before next group DBSPACETEMP # Default temp dbspaces DUMPDIR /opt/informix/tmp # Preserve diagnostics in this directory DUMPSHMEM 0 # Dump a copy of shared memory DUMPGCORE 0 # Dump a core image using 'gcore' DUMPCORE 0 # Dump a core image (Warning:this aborts OnLine) DUMPCNT 1 # Number of shared memory or gcore dumps for FILLFACTOR 75 # Fill factor for building indexes USEOSTIME 1 # 0: use internal time(fast), 1: get time from OS(slow) MAX_PDQPRIORITY 100 # Maximum allowed pdqpriority DS_MAX_QUERIES # Maximum number of decision support queries DS_TOTAL_MEMORY # Decision support memory (Kbytes) DS_MAX_SCANS 1048576 # Maximum number of decision support scans DATASKIP off # List of dbspaces to skip OPTCOMPIND 2 # To hint the optimizer DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default) or OFF (0) ONDBSPACEDOWN 0 # Dbspace down option: 0 = CONTINUE, 1 = ABORT, 2 = WAIT OPCACHEMAX 0 # Maximum optical cache size (Kbytes) HETERO_COMMIT 0 SBSPACENAME # Default smartblob space name - this is where blobs SYSSBSPACENAME # Default smartblob space for use by the Informix BLOCKTIMEOUT 3600 # Default timeout for system block SYSALARMPROGRAM /opt/informix/etc/evidence.sh # System Alarm program path OPT_GOAL -1 ALLOW_NEWLINE 0 # embedded newlines(Yes = 1, No = 0 or anything but 1) JVPJAVAHOME /opt/informix/extend/krakatoa/jre JVPHOME /opt/informix/extend/krakatoa # Krakatoa installation directory JVPPROPFILE /opt/informix/extend/krakatoa/.jvpprops # JVP property file JVPLOGFILE /opt/informix/jvp.log # JVP log file. JDKVERSION 1.3 # JDK version supported by this server JVPJAVALIB /lib/i386/ JVPJAVAVM hpi:server:verify:java:net:zip:jpeg JVPCLASSPATH /opt/informix/extend/krakatoa/krakatoa.jar:/opt/informix/extend/krakatoa/jdbc.jar "onstat -p" IBM Informix Dynamic Server Version 9.40.UC5 -- On-Line -- Up 78 days 20:57:57 -- 809164 Kbytes Profile dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached 446114098 448452959 2119132990 78.95 740704 1737439 14412520 94.86 isamtot open start read write rewrite delete commit rollbk 435696143 2308895 7630873 382984820 4310736 663812 1459576 16128 0 gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs 0 0 0 0 0 0 0 ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes 0 0 0 12801.87 5044.02 264 1352 bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans 9353974 0 167482445 0 0 15 132173 772809 ixda-RA idx-RA da-RA RA-pgsused lchwaits 5656795 189779 439030536 444874058 1362060 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2005, 17:04 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
Видно множество проблемных мест, но не хочется снова писать об одном и том же. Очень рекомендую почитать недавнюю ветку в конференции ukr.comp.dbms.informix или ее отражение на Гугле http://groups-beta.google.com/group/ukr.comp.dbms.informix/browse_frm/thread/7582ca5e94b5b991/0de3d099b2e7f930?q=%D0%95%D1%81%D1%82%D1%8C+%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%B0+%D1%81+7.31+UD5+%D0%BF%D0%BE%D0%B4&_done=%2Fgroups%3Fsourceid%3Dnavclient%26ie%3DUTF-8%26rls%3DGGLC,GGLC:1970-01,GGLC:en%26q%3D%D0%95%D1%81%D1%82%D1%8C+%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%B0+%D1%81+7.31+UD5+%D0%BF%D0%BE%D0%B4%26&_doneTitle=Back+to+Search&&d#0de3d099b2e7f930 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2005, 20:45 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
vasilisВидно множество проблемных мест, но не хочется снова писать об одном и том же. Очень рекомендую почитать недавнюю ветку в конференции ukr.comp.dbms.informix или ее отражение на Гугле http://groups-beta.google.com/group/ukr.comp.dbms.informix/browse_frm/thread/7582ca5e94b5b991/0de3d099b2e7f930?q=%D0%95%D1%81%D1%82%D1%8C+%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%B0+%D1%81+7.31+UD5+%D0%BF%D0%BE%D0%B4&_done=%2Fgroups%3Fsourceid%3Dnavclient%26ie%3DUTF-8%26rls%3DGGLC,GGLC:1970-01,GGLC:en%26q%3D%D0%95%D1%81%D1%82%D1%8C+%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%B0+%D1%81+7.31+UD5+%D0%BF%D0%BE%D0%B4%26&_doneTitle=Back+to+Search&&d#0de3d099b2e7f930 похоже что я как раз и наступил на большую часть граблей, о которых описывается в данном треде (количество LRU, CLEANERS, частота запуска чекпоинтов и т.д.) буду экспериментировать на тестовом серевере, потом переносить на боевой, а потом опять буду задавать вопросы... Сенькс! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 10:17 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
genixпохоже что я как раз и наступил на большую часть граблей, о которых описывается в данном треде (количество LRU, CLEANERS, частота запуска чекпоинтов и т.д.) А где грабли с частотой чекпоинтов? Обрати внимание на: LTXHWM 70 LTXEHWM 80 Огромный риск LTXHWM 45 LTXEHWM 54 DBSPACETEMP Обязательно нужен дибиспейс с типом темп NUMCPUVPS 2 # Number of user (cpu) vps AFF_SPROC 0 # Affinity start processor AFF_NPROCS 4 Процессоров CPU - 2, а забиндится им предложено на 4 физ. проца? FILLFACTOR 75 Никогда не видел что бы кто-то менял стандартное значение 90 ? ROOTSIZE 10241406 - 10 Гб я глючу? Вы чего там данные храните? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 11:19 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис ROOTSIZE 10241406 - 10 Гб я глючу? Вы чего там данные храните? Нет, только sysmaster, sysutils и sysuser. Пожалуй действительно, 10 Гб это многовато Все остальные замечания учту и постараюсь исправить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 11:29 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
genixНет, только sysmaster, sysutils и sysuser. Пожалуй действительно, 10 Гб это многовато Мегабайтов 200-250 должно хватить. PHYSBUFF 512 # Physical log buffer size (Kbytes) LOGBUFF 512 # Logical log buffer size (Kbytes) Кто и зачем изменил стандартные значения? Это от большого ума или просто руки некуда девать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 11:41 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис PHYSBUFF 512 # Physical log buffer size (Kbytes) LOGBUFF 512 # Logical log buffer size (Kbytes) Кто и зачем изменил стандартные значения? Это от большого ума или просто руки некуда девать? именно второй вариант ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 12:13 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Обрати внимание на: LTXHWM 70 LTXEHWM 80 Огромный риск LTXHWM 45 LTXEHWM 54 На самом деле, не все так страшно. Обрати внимание :) что это версия 9.4 и DYNAMIC_LOGS 2, т.е. включено динамическое добавление журналов. Сам я рекомендую эту фичу выключать (видел пару раз системы, в которых такие вот "динамически добавленные логи" были разбросаны по всем пространствам и суммарным объемом в гигабайты (вот такие у них длинные транзакции :)), а люди даже не подозревали об этом, только жутко ругались на "томознутость" Информикса. Но в данном случае значения LTXHWM 70 и LTXEHWM 80 не являются опасными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 21:29 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис genixНет, только sysmaster, sysutils и sysuser. Пожалуй действительно, 10 Гб это многовато Мегабайтов 200-250 должно хватить. Тут надо учитывать, что в rootdbs наверняка лежит физжурнал размером в 200М и могут лежать все логические журналы (20 штук по 100М) - может именно поэтому и такой огромный rootdbs ? так что сначала эти журналы надо вынести на отдельные пространства. Вот тогда указанного размера корневого пространства будет вполне достаточно для системных данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 21:37 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
vasilis Журавлев Денис genixНет, только sysmaster, sysutils и sysuser. Пожалуй действительно, 10 Гб это многовато Мегабайтов 200-250 должно хватить. Тут надо учитывать, что в rootdbs наверняка лежит физжурнал размером в 200М и могут лежать все логические журналы (20 штук по 100М) - может именно поэтому и такой огромный rootdbs ? так что сначала эти журналы надо вынести на отдельные пространства. Вот тогда указанного размера корневого пространства будет вполне достаточно для системных данных. получается меньше 3 гиг, плюс 7 гиг для темпов наверное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 09:04 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
vasilis Журавлев Денис Обрати внимание на: LTXHWM 70 LTXEHWM 80 Огромный риск LTXHWM 45 LTXEHWM 54 На самом деле, не все так страшно. Обрати внимание :) что это версия 9.4 и DYNAMIC_LOGS 2, т.е. включено динамическое добавление журналов. А точно. vasilis Сам я рекомендую эту фичу выключать (видел пару раз системы, в которых такие вот "динамически добавленные логи" были разбросаны по всем пространствам и суммарным объемом в гигабайты (вот такие у них длинные транзакции :)), а люди даже не подозревали об этом, только жутко ругались на "томознутость" Информикса. Но в данном случае значения LTXHWM 70 и LTXEHWM 80 не являются опасными. Я один раз тоже вычищал логи раскиданные по всем спейсам, больше не хочу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 09:06 |
|
||
|
Несколько вопросов по оптимизации СУБД
|
|||
|---|---|---|---|
|
#18+
Приветствую всех еще раз! Довелось мне поменять некоторые значения, о которых шла речь в этом треде. В частности: onconfig -NUMCPUVPS 2 # Number of user (cpu) vps +NUMCPUVPS 4 # Number of user (cpu) vps -PHYSBUFF 512 # Physical log buffer size (Kbytes) -LOGBUFF 512 # Logical log buffer size (Kbytes) -CLEANERS 2 # Number of buffer cleaner processes +PHYSBUFF 32 # Physical log buffer size (Kbytes) +LOGBUFF 32 # Logical log buffer size (Kbytes) +CLEANERS 12 # Number of buffer cleaner processes -DYNAMIC_LOGS 2 -LTXHWM 70 -LTXEHWM 80 +DYNAMIC_LOGS 1 +LTXHWM 45 +LTXEHWM 54 -DBSPACETEMP # Default temp dbspaces +DBSPACETEMP temp # Default temp dbspaces -FILLFACTOR 75 # Fill factor for building indexes +FILLFACTOR 90 # Fill factor for building indexes что еще посоветуете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 18:12 |
|
||
|
|

start [/forum/topic.php?fid=44&msg=32895282&tid=1609108]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
49ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
83ms |
get tp. blocked users: |
2ms |
| others: | 245ms |
| total: | 431ms |

| 0 / 0 |
