Подскажите, пожалуйста:

1) документацию по вопросам оптимизации производительности
2) как можно следить (вести логи) активности пользователей? а именно кто в данный момент выполняет какой запрос и сколько CPU использует данный пользователь? есть ли что-то более продвинутое, чем onstat -g sql? хотелось бы видеть всю историю запросов включая время их выполнения. Можно такое сделать?

Журавлев Денис
genix ты задаешь тучи вопросов, но ответов не получаешь. А знаешь почему? Потому что ты пытаешься применить практики знакомые тебе по другим СУБД. Не говори у меня такие-то проблемы, раскажи сначала про задачу. Ты на первом повороте пошел не в ту сторону, зашел в дремучий лес и теперь спрашиваешь где выход?

Ну что-ж, попробую начать новую жизнь! $)

Итак, на небольшой базе под IDS 7.31.UD2 время от времени простенькие запросы к небольшой табличке выполняются разное количество времени.
Т.е., 99% времени они выполняются в среднем быстрее 1 секунды, однако иногда выполнение длится дольше 3 секунд и даже дольше 8 (доходило до 10).
Соответственно работа клиентов в этот момент блокируется (на некоторое время).
Соответсвено я сделал вывод (возможно не правильный), что кто-то в этот момент нагружает СУБД своими садистскими запросами.
Подскажите, с чего начать анализ происходящего в системе и разобраться с происходящим?

Доп. инфо: количество ovbuf (смотрю по onstat -p) в этот момент не увеличивается (оно уже давно стоит в значении 332), остальные ov[lock|userthread] нулевые.

спасибо всем, завтра буду разбираться подробнее!!

"vmstat"
procsyssqlcurseos y memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
1 0 0 20176 11820 19940 864956 0 0 0 1 1 0 0 0 1


а также

"iostat"
Linux 2.4.22 ( ) 28.01.2005

avg-cpu: %user %nice %sys %idle
1,86 0,00 0,12 98,01

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn



Выводы onstat очень большие, стоит ли приводить их? Если да, то какие части?
Смущает вот это:

"onstat -g all"
Virtual processor summary:
class vps usercpu syscpu total
cpu 1 344444.70 4371.33 348816.03
aio 48 2956.30 5790.85 8747.15
lio 1 11.51 53.15 64.66
pio 1 11.42 57.28 68.70
adm 1 64.16 109.97 174.13
soc 1 409.22 1614.68 2023.90
msc 1 15.01 7.76 22.77
total 54 347912.32 12005.02 359917.34


то что cpu = 1, хотя машина 2х процессорная. Корректно ли это с точки зрения оптимизации работы informix'а?

Журавлев Денис
А где сказано что запрос(ы?) читают? -- "Т.е., 99% времени они выполняются в среднем быстрее 1 секунды..."

тестирую запросами на чтение (количество секунд задержки соответствует 1 писку из спикера)

Журавлев Денис
Q.> когда поглядел onstat -u вот что увидел
>Userthreads
>address flags sessid user tty wait tout locks nreads nwrites
>1012e018 ---P--D 1 informix - 0 0 0 139 372
> ^^^^
> этих флажков
> я зе знаю


встречаются в основном такие :
пользовательские сессии:
2301e55c Y--P--- (около 30 шт)
2301ea58 Y-BP--- (2 шт)

root'овые сесии:
23010510 ---P--F (4 шт, пользователь root)
23012cf0 ---P--D (2 шт. пользователь root)
23011dfc ---P--B (1 шт, пользователь root)

итого
37 active, 128 total, 58 maximum concurrent

vasilis
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

Спасибо, попробую!

vasilisИ еще меня смущают следующие цифры
Virtual processor summary:
class vps usercpu syscpu total
cpu 1 344444.70 4371.33 348816.03

Это за какой же период собрана статистика ?
И уж больно большое соотношение usercpu к syscpu.
Или ввода/вівода очень мало или ...что то тут не так :)

если под периодом понимается uptime который можно посмотреть по onstat, то речь идет всего лишь о 110 днях

vasilis
выполни лучше запрос по анализу загрузки проца. Только сначала обнули статистику, дай активно поработать серверу с час и покажи результат


теперь только в понедельник смогу ответить.

Еще раз премного благодарен за проявленое терпение!!!!!

1) добавил еще один процессор, без перезагрузки oninit
2) обновил статистику
3) на сервере запустили построение реестра, которое обычно приводило к "задержкам" во время выполнения остальных запросов чтения. Пока все нормально, программа-детектор (которая пищала при тормозах) подозрительно молчит, простой (idle) процессоров (по sar) падает ниже 50% (раньше опускался минимум до 50, ниже нет) -- полагаю что это благодатное следствие работы на двух процессорах вместо одного.
4) запрос имени vasilis выдает:

______________ ===== CPU Profile ====
hostname xxxx.xxxxxxxx
boot_time 2004-10-10 13:49:03
_running_time 112 20:35:41
zero_profile_time 2005-01-31 08:41:00
statistic_time 0 01:43:44
______________ -------------------------------
__________ --Onconfig Effective--
num_cpuvps 2
multiprocessor 1
______________ -------------------------------
__________ -- Stamp activity from boot --
boot_stamp 655519076
current_stamp 967678658
_stamp_update 312159582
_activity_psec 32.0015


Спасибо, что не дали пропасть в трудный момент!
Премного благодарен за все полученные советы (в том числе и как правильно задавать вопросы)!

vasilisК сожалению, концовку вывода запроса ты обрезал. тас как раз и хотел посмотреть загрузку процессоров.

О-пс, посыпаю голову пеплом -- результат запроса оказался двухстраничным $)

vasilis
Но раз помогло. то уже хорошо.
На будущее, можно указать в onconfig даже три или четыре CPU VP на двух физических процессорах

А как лучше быть на 2-х процессорах с HT (Intel Xeon)? Указывать 2 (физических) или 4 (с учетом HT) процессора? Система (linux) видит в общей сложности 4 процессора.

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
______________ -------------------------------

Журавлев Денис
Коды флага для 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Гб оператвки на сервере?

Оценить уровень кеширования можно посмотрев 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

Покажи вывод 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

Журавлев Денис
Здесь отображается сколько и как информикс использует память.

Строка с классом 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

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, частота запуска чекпоинтов и т.д.)
буду экспериментировать на тестовом серевере, потом переносить на боевой, а потом опять буду задавать вопросы...

Сенькс!

Журавлев Денис
ROOTSIZE 10241406 - 10 Гб я глючу? Вы чего там данные храните?

Нет, только sysmaster, sysutils и sysuser.
Пожалуй действительно, 10 Гб это многовато

Все остальные замечания учту и постараюсь исправить.

Журавлев Денис
PHYSBUFF 512 # Physical log buffer size (Kbytes)
LOGBUFF 512 # Logical log buffer size (Kbytes)
Кто и зачем изменил стандартные значения? Это от большого ума или просто руки некуда девать?

именно второй вариант

Приветствую всех еще раз!

Довелось мне поменять некоторые значения, о которых шла речь в этом треде.
В частности:


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


что еще посоветуете?