ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Informix [игнор отключен] [закрыт для гостей] / Производительность сервера
25 сообщений из 67, страница 2 из 3
  2  все
Производительность сервера
    #35049482
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
KrukovSEДоброе всем утро и спасибо за внимание!

onstat -a получился аж на 12 метров, может из него что конкретное надо ?
пожать и выложить на slil.ru

KrukovSE
Сегодня поднял еше кол-во буферов до 2000000 и перезапустил Информикс.
что теперь free показывает?

KrukovSE
Вчерашние запросы выполнявшиеся по 2 мин, отрабатывают сегодня за 40 сек.
После отработки запроса, повторные его запуски отрабатывают за 1-2 сек.
А до перехода сколько они выполнялись? Может статистика не собрана? План запроса съехал?
...
Рейтинг: 0 / 0
09.01.2008, 11:42
| Ответить | Цитировать | Написать  
Производительность сервера
    #35049485
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
KrukovSE



Если посмотреть на конфигурацию которую вы сделали
в ней ИМХО есть несколько неприятных моментов:

1. Объединив все диски в один большой том вы потенциально сделали бутылочное горлышко в драйвере ОС.
когда iostat -x >iostat.log в поле avgqu-sz будет иметь значение больше 10 считайте что вы в него попали.

2. Уменьшив размер страницы до 2 К вы будете иметь потенциальную проблему с исчерпыванием количества страниц табличном пространстве.
Это значение ограничено приблизительно 16 000 000 страниц.
Когда они исчерпаются записи в таблицу вы добавить не сможете.
Точно ошибку я не помню, звучит она что то типа "no more extents"
Посмотреть количество страниц в табличном пространстве можно через oncheck -pt ......
...
Рейтинг: 0 / 0
09.01.2008, 11:43
| Ответить | Цитировать | Написать  
Производительность сервера
    #35049494
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
onstat-
1. Объединив все диски в один большой том вы потенциально сделали бутылочное горлышко в драйвере ОС.
С 10-ю дисками? Не думаю. В дисковый массив раньше упрется.
...
Рейтинг: 0 / 0
09.01.2008, 11:46
| Ответить | Цитировать | Написать  
Производительность сервера
    #35049545
KrukovSE
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KrukovSE
Гость
По поводу чекпоинтов -

10:44:25 Maximum server connections 182
10:44:27 Checkpoint Completed: duration was 0 seconds.
10:44:27 Checkpoint loguniq 23, logpos 0x586018, timestamp: 0xd799cd7

10:44:27 Maximum server connections 182
10:44:29 Checkpoint Completed: duration was 1 seconds.
10:44:29 Checkpoint loguniq 23, logpos 0x587018, timestamp: 0xd79f6d7

10:44:29 Maximum server connections 182
10:44:31 Checkpoint Completed: duration was 1 seconds.
10:44:31 Checkpoint loguniq 23, logpos 0x588018, timestamp: 0xd7a5c63

10:44:31 Maximum server connections 182
10:44:33 Checkpoint Completed: duration was 1 seconds.
10:44:33 Checkpoint loguniq 23, logpos 0x589018, timestamp: 0xd7ab8cc

10:44:33 Maximum server connections 182
10:44:35 Checkpoint Completed: duration was 1 seconds.
10:44:35 Checkpoint loguniq 23, logpos 0x58a018, timestamp: 0xd7b1035

Дисковый массив 10 рейд на DS4300 - 14 Fiber SCSI 15.000 по 36G - довольно быстрая железяка :)

В предыдущем варианте МАХ у нас работал на IDS7 и Unixware масив был разбит на чанки
по 2г.
Приобрели RedHat 4(64) b Informix 10 вендор разбил дисковый массив на 2 раздела DBS и USR
Со временем размеры баз выросли и места стало на DBS нехватать, поэтому и объединили
в 1 раздел.
Массив разбил fdisk на rootdbs, tmpdbs, dbs. Неформатировал разделы.


Код: plaintext
1.
2.
3.
4.
-sh-3.00$ free                                                           
             total       used       free     shared    buffers     cached
Mem:      15890596    8402804    7487792          0     218052    7594264
-/+ buffers/cache:     590488   15300108                                 
Swap:      2032212          0    2032212


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
iostat -i
Linux 2.6.9-22.ELsmp (max) 	09.01.2008

CPU-average:%user   %nice    %sys %iowait   %idle
           6,64    0,00    5,02    0,03   88,32

Devices: rrqm/s wrqm/s   r/s   w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda          0,01  21,31  0,13  8,62    2,83  239,43     1,42   119,72    27,71     0,10   11,51   0,34   0,30
sdb          0,04   0,39 455,35 82,91 6385,13 2535,54  3192,56  1267,77    16,57     2,32    4,30   0,88  47,62
sdc          0,00   0,00  0,00  0,00    0,00    0,00     0,00     0,00    48,86     0,00    2,19   2,19   0,00
...
Рейтинг: 0 / 0
09.01.2008, 12:01
| Ответить | Цитировать | Написать  
Производительность сервера
    #35049561
KrukovSE
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KrukovSE
Гость
onstat -a

http://slil.ru/25332757
...
Рейтинг: 0 / 0
09.01.2008, 12:07
| Ответить | Цитировать | Написать  
Производительность сервера
    #35049600
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
Журавлев Денис onstat-
1. Объединив все диски в один большой том вы потенциально сделали бутылочное горлышко в драйвере ОС.
С 10-ю дисками? Не думаю. В дисковый массив раньше упрется.

В этой конфигурации тяжело сказать где раньше упрется.
Если даже упрется в контроллер то большая очередь операций ВВ как раз об этом и говорит.
Большая очередь это следствие, а не причина.
Причины глубже.
Утилиты контролера могут показывать что там еще полно свободных ресурсов, но из за
сериализации доступа( например на операции записи) к единственному тому контроллер
их просто задействовать их не сможет. Было бы несколько томов( второй том контролеер мог бы паралельно читать), и очередь в дарйвере была бы короче и контроллер
нагружен лучше, а следственно и производительность выше.
...
Рейтинг: 0 / 0
09.01.2008, 12:17
| Ответить | Цитировать | Написать  
Производительность сервера
    #35049791
Алексан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексан
Участник
KrukovSEonstat -l
IBM Informix Dynamic Server Version 10.00.FC3R1 -- On-Line (CKPT REQ) -- Up 01:46:22 -- 6552712 Kbytes
Blocked:CKPT

Physical Logging
Buffer bufused bufsize numpages numwrits pages/io
P-2 0 16 2672530 179354 14.90
phybegin physize phypos phyused %used
1:263 5000 4996 3753 75.06

Logical Logging
Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
L-1 0 16 777 765 765 1.0 1.0
Subsystem numrecs Log Space used
OLDRSAM 777 28148
...Я бы увеличил PHYZBUF до 128 (возможно и больше, смотря по результатам...). На большинстве запросов это не скажется, но некоторые могут заметно ускориться.
Из Ваших предыдущих сообщений я понял, что раньше база данных лежала в dbspace'е с размером страницы 16Кб, а ныне - с размером 2 Кб - это правильно? И данные и индексы лежат в одном dbspace'е? Переход к меньшему размеру страницы для индексов мог привести к значительному увеличению их высоты и, как следствие, к замедлению выполнения запроса. Часто ли вы обновляете статистику? Можете выполнить такой запрос к Вашей базе данных:
SELECT idxname, owner, tabid, idxtype, clustered, levels, leaves, nunique, clust FROM sysindexes ORDER BY levels DESC
...
Рейтинг: 0 / 0
09.01.2008, 13:10
| Ответить | Цитировать | Написать  
Производительность сервера
    #35049928
KrukovSE
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KrukovSE
Гость
Статистику обновляем редко - работа круглосуточная :(
Результат запроса (часть):

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
idxname		owner	tabid	idxtype	clustered	levels	leaves	nunique	clust
nvtrn_keyciss	informix	285	U		6	704234	6101839	4614795
nvtrn_serkey	maxmast	285	D		5	184417	2724337	15199270
nvtrn_serkey1	maxmast	285	D		5	199677	2724337	15167747
nvtrn_to	maxmast	285	D		5	102183	122883	15743744
imcst_key	maxmast	212	U		5	1527142	409004	2495810
nvtrs_listkey	maxmast	286	U		5	9005	96	11249
nvtrs_listkey2	maxmast	286	U		5	9454	96	11249
mftrn_key	maxmast	235	D		5	29784	3	204772
imsur_remser	maxmast	222	D		5	37254	61359	96752
imsur_conitmser	maxmast	222	D		5	31193	889	189254
nvtrn_origkey	maxmast	285	D		5	404909	6102027	4615167
imsu_key	maxmast	220	U		5	131198	156228	1804723
imctp_key	maxmast	214	U		5	94337	413526	210638
nvtrn_latest	maxmast	285	U		5	614442	122883	15723447
crrel_itemkey	maxmast	162	U		5	8672	11105	8891
nvtrn_postkey	maxmast	285	U		5	307056	2	4613385
nvtrn_key	maxmast	285	U		5	297440	6101839	4614614
nvtrn_glrefkey	maxmast	285	U		5	614272	116	4625640
nvtrn_fromto	maxmast	285	D		5	109353	122883	15743321
nvtrn_from	maxmast	285	D		5	101253	122883	15740976
nvtrn_datekey	maxmast	285	D		5	354880	122883	15723209
nvtrn_datecurr	maxmast	285	U		5	404426	1523	3348484
glt_yroperkey	maxmast	207	U		5	285800	4	1943990
glt_uzkey	maxmast	207	U		5	420314	4	1589615
glt_linkkey	maxmast	207	U		5	246379	14198540	1590063
glt_key5	maxmast	207	U		5	304046	20376	1593211
glt_key2	maxmast	207	U		5	317565	1825	1663073
glt_key	maxmast	207	U		5	386219	1825	1663060
uzmfo_uzworkkey	maxmast	486	D		5	41167	2	1078706
rtop_key	maxmast	358	U		5	41985	199042	253203
rtres_key	maxmast	359	U		5	101328	198572	189242
pst_uokey	maxmast	342	U		5	40080	193797	644686
rtres_opkey	maxmast	359	D		5	48229	198572	189242
pst_orgkey	maxmast	342	U		5	40102	1	259019
rthed_key	maxmast	356	U		4	5530	216245	44653
imsul_storekey	maxmast	539	D		4	5312	173	32996
uzmfo_key2	maxmast	486	U		4	30828	22658	303319
uzmfo_key3	maxmast	486	U		4	30828	22658	303319
rtop_hedkey	maxmast	358	D		4	11723	199042	253203
purel_datekey	maxmast	349	U		4	2872	29720	22530
prhed_extkey	maxmast	338	U		4	1857	4508	16425
prhed_key1	maxmast	338	U		4	1985	1374	19411
purel_imskey	maxmast	349	U		4	3618	29720	22528
uzmfo_workkey	maxmast	486	D		4	24829	2	1181830
uzprk_key	maxmast	497	U		4	3822	11044	4608
purel_revkey	maxmast	349	U		4	2872	29720	22530
uzrb_key	maxmast	500	U		4	32770	26796	599104
imsul_serbinkey	maxmast	539	D		4	5356	138664	32894
imsul_key2	maxmast	539	U		4	9414	173	32901
colin_item	maxmast	150	D		4	1749	30247	41319
txt_key	maxmast	435	U		4	2636	2	7842
pst_main_key	maxmast	342	U		4	25313	344015	259019
imsul_key	maxmast	539	U		4	9389	32325	34957
imast_itmanf	maxmast	210	U		4	8314	413136	265647
imsul_binkey	maxmast	539	U		4	9413	173	32929
satrn_key	maxmast	361	U		4	668	9336	4668
saytd_sakey	maxmast	362	U		4	519	9334	934
uzmfoh_key	maxmast	524	U		4	17073	6081	161862
uzmfoh_uzworkkey	maxmast	524	D		4	14492	2	334211

physbuf - 128 попробую попозже, окошко будет.

Спасибо.
...
Рейтинг: 0 / 0
09.01.2008, 13:42
| Ответить | Цитировать | Написать  
Производительность сервера
    #35050340
Алексан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексан
Участник
KrukovSEСтатистику обновляем редко - работа круглосуточная :(Это Вы зря. Если статистика неадекватная, никакие настройки сервера не помогут.

KrukovSEРезультат запроса (часть):

idxname owner tabid idxtype clustered levels leaves nunique clust
nvtrn_keyciss informix 285 U 6 704234 6101839 4614795
nvtrn_serkey maxmast 285 D 5 184417 2724337 15199270
nvtrn_serkey1 maxmast 285 D 5 199677 2724337 15167747
... Ничего особо выдающегося, как хорошего, так и плохого. В большой базе ничего другого ожидать не приходится...
А то, что после заполнения кэша запросы выполняются за 1-2 секунды, решило ваши проблемы?
...
Рейтинг: 0 / 0
09.01.2008, 15:30
| Ответить | Цитировать | Написать  
Производительность сервера
    #35050485
KrukovSE
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KrukovSE
Гость
На данный момент жалоб нет, посмотрим когда запустят расчеты MRP (пока их непроизводили)
А вообсче, благодаря этой проблемке, у меня сложилось впечатление что из нашего сервера
можно было выжать гораздо больше чем было со с настройками продавца ПО. :)

Спасибо всем, за помощь :)


Есче мыслишка...
Есть у нас еше SATA стойка и места на ней хватает, как промежуточный вариант можно сделать
есче один дбспейс слить туда базы и переделать основной массив :)
Только есть проблема: заливка баз и создание индексов идут двое суток.
Можно попробовать onunload вместо dbimport, но это тоже время.
Можно ли каким-либо другим образом переместить базу с одного dbspace в другой вместе с индексами?
...
Рейтинг: 0 / 0
09.01.2008, 16:02
| Ответить | Цитировать | Написать  
Производительность сервера
    #35050630
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
KrukovSEНа данный момент жалоб нет, посмотрим когда запустят расчеты MRP (пока их непроизводили)
А вообсче, благодаря этой проблемке, у меня сложилось впечатление что из нашего сервера
можно было выжать гораздо больше чем было со с настройками продавца ПО. :)

Спасибо всем, за помощь :)


Есче мыслишка...
Есть у нас еше SATA стойка и места на ней хватает, как промежуточный вариант можно сделать
есче один дбспейс слить туда базы и переделать основной массив :)
Только есть проблема: заливка баз и создание индексов идут двое суток.
Можно попробовать onunload вместо dbimport, но это тоже время.
Можно ли каким-либо другим образом переместить базу с одного dbspace в другой вместе с индексами?

Если стоит задача минимизировать простой то можно, только очень акуратно,
с помощью alter fragment превести заполнение таблиц
в новый dbspace( на новом массиве), и через несколько месяцев когда старыми данными никто ( или практически никто)
активно пользоваться уже не будет, сделать detach старого фрагмента в отдельную таблицу,
затем через insert ... select перенести записи в новую.
Едиственное нужно будет перестроить уникальные индексы, потому как они фрагментируются только тогда, когда условие фрагментации таблицы присутствует в индексе.
То есть уникальные индексы полность останутся в старом dbspace.

Если делать все внимательно и все зараннее просчитав и протестировав , проблем быть не должно.
...
Рейтинг: 0 / 0
09.01.2008, 16:33
| Ответить | Цитировать | Написать  
Производительность сервера
    #35051402
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
KrukovSEЕсче мыслишка...
Есть у нас еше SATA стойка и места на ней хватает, как промежуточный вариант можно сделать
есче один дбспейс слить туда базы и переделать основной массив :)
Только есть проблема: заливка баз и создание индексов идут двое суток.
Можно попробовать onunload вместо dbimport, но это тоже время.
Можно ли каким-либо другим образом переместить базу с одного dbspace в другой вместе с индексами?
Можно.
Использовать зеркалирование средствами Информикс.
Создать зеркало всех пространств того же размера на новом массиве , подождать пока синхронизируется (на это время производительность просядет, но можно сделать ночью), а затем разорвать зеркало, отключив основной массив (не физически, конечно :)
К сожалению, потом, для возврата на основной, уже переразбитый массив, уже нельзя будет применить ту же технологию.
Кстати, если есть допол.массив, то выполнить переразбивку можно сразу - создать там несколько dbspaces с нужными размерами страниц (и с чанками размером по 10-20Г) и переносить таблицы по одной стандартным alter fragment (вместе с индексами). Для больших таблиц могут быть длинные транзакции (добавить лог.жуурналов) и блокировки, но на ночь можно оставлять.
А затем использовать зеркалирование для возврата на основной массив.
На всякий случай напомню, что при любых операциях желательно страховаться бэкапами :)
...
Рейтинг: 0 / 0
09.01.2008, 21:39
| Ответить | Цитировать | Написать  
Производительность сервера
    #35051479
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
Из беглого анализа информации могу заметить:
- очень маленький размер физжурнала (10М для такой нагрузки могут вылезти боком)
- недопустимо маленькое число LRUS (обязательно увеличить для такого размера кеша)
- обязательно увеличить CLEANERS
- можно вообще убрать кеш для 16К страниц, раз их пока нет в ДБ-пространствах (только зря память расходуется)
- обязательно хорошо увеличить SHMVIRTSIZE (кажется, кто то уже говорил)
- советовал бы установит RA_PAGES и RA_THRESHOLD в значения хотя бы 64 32
- странно маленькое число транзакций (то ли у вас не OLTP, то ли специфика приложения...)
- довольно странное (как для меня) соотношение usercpu и syscpu (78002.31 41276.13)
обычно на тех тяжелых системах, что я вижу, соотношение не ниже 80 к 20, а здесь в основном идет работа с дисками (в том числе и tempdbs). Я бы лучше сделал 2 или 3 tempdbs суммарно того же размера.
И несколько вопросов:
"после переразбивки 240г залили бызы" - как залили ? dbimport-ом ?
А статистика там точно собиралась или сократили за недостатком времени на миграцию ?
Почему то мне кажется, что оптимальный сбор статистики вам бы очень помог :)
А процов 8 честных или это 4-е 2-х ядерных или два по 4 ?
А системный /tmp на 5-м рейде ? А не стоит ли в окружении PSORT_DBTEMP на него ?
И почему бы не поставить PSORT_NPROCS=4 (например) ?
...
Рейтинг: 0 / 0
09.01.2008, 22:58
| Ответить | Цитировать | Написать  
Производительность сервера
    #35051982
KrukovSE
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KrukovSE
Гость
Упс, столько вопросов...
Продолжаем изучать информикс :)

После переразбивки 240г залили бызы dbimport-ом.
Cтатистика точно собиралась.
Процессоров - 8 честных ( 2 ящика IBMx460 по 4CPU) (нравится мне эта железяка :) )
Системный tmp точно на 5 рейде из 3х дисков, там же и swap для системы.
В окружении PSORT_DBTEMP и PSORT_NPROCS=4 вообще не выставлены .......
как я прочитал
"Необходимо отметить, что, если установлен параметр DBSPACETEMP или переменная окружения DBSPACETEMP, то для записи временных файлов при сортировках используются указанные dbspace’ы. Если они не установлены и не установлена переменная PSORT_DBTEMP, то используется директория /tmp".

На тему дбспейсов: у нас на массиве из 14 дисков - 1рейд 10го уровня, затем ентот
большой диск разбит на rootdbs, tmpdbs, dbs. В плане производительности это нормальный вариант
или лучше создать например 2массива 10 рейда например rootdbs+tmpdbs и dbs?

На счет изменения остальных переменных - обязательно попробую, только ввот время на остановку
сервера выбить очень тяжело.
...
Рейтинг: 0 / 0
10.01.2008, 10:49
| Ответить | Цитировать | Написать  
Производительность сервера
    #35052009
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
PHYSFILE маловат, из-за этого имеем достаточно частые чекпоинты.
Я так понимаю, смысла увеличивать CLEANERS нету, поскольку все "официанты" (CLEANERS-ы) будут толкаться все равно за одним "столом" (чанком). Т.е. до добавления новых чанков смысла нет.
LRUS все равно не используется и если не трогать LRU_MAX_DIRTY, LRU_MIN_DIRTY использоватся скорее всего не будет.
...
Рейтинг: 0 / 0
10.01.2008, 10:57
| Ответить | Цитировать | Написать  
Производительность сервера
    #35052110
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
Стоит учесть, что с параметрами надо играться комплексно. Увеличив PHYSFILE без разбиения чанков, увеличения cleanears и игры с LRUS-ами, у вас получится скорее всего следующая ситуация. Общая производительность системы вырастет. Но появится проблема "длинный чекпоинт", во время которой запросы пользователей будут терпеливо ждать, пока он закончится. Для длительных запросов скорее всего время ожидания будет несущественно, но для коротеньких оно вылезет боком. Поэтому впервую очередь, я задумался бы о создании нового dbspace и постепенного переноса туда хотя бы маленьких табличех.
Учитывая, что любый табличные операции вызовут простой системы, получаем, что без особого ущерба и длительной остановки все что можно сделать - выполнить советы Василия по temp-у. Ну и PHYSFILE, только не меняйте его слишком резко, помониторьте как изменятся чекпоинты (их частота и длительность).
...
Рейтинг: 0 / 0
10.01.2008, 11:21
| Ответить | Цитировать | Написать  
Производительность сервера
    #35052147
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Алексан... Переход к меньшему размеру страницы для индексов мог привести к значительному увеличению их высоты и, как следствие, к замедлению выполнения запроса.
LOG(100000000;16348) =~ 2
LOG(100000000;2048) =~ 2

А еще возможно уменьшилась конкуренция за хотблоки поэтому возможно многие олтп запросы ускорились.
...
Рейтинг: 0 / 0
10.01.2008, 11:30
| Ответить | Цитировать | Написать  
Производительность сервера
    #35052163
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
KrukovSE...
Есче мыслишка...
Есть у нас еше SATA стойка и места на ней хватает, как промежуточный вариант можно сделать
есче один дбспейс слить туда базы и переделать основной массив :)
Только есть проблема: заливка баз и создание индексов идут двое суток.
Можно попробовать onunload вместо dbimport, но это тоже время.
Можно ли каким-либо другим образом переместить базу с одного dbspace в другой вместе с индексами?Зачем вам этот гемор? Если вы не знаете в чем ваши проблемы, зачем пробовать все лекарства подряд? Это может вас убить.
...
Рейтинг: 0 / 0
10.01.2008, 11:32
| Ответить | Цитировать | Написать  
Производительность сервера
    #35052170
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
onstat-
Большая очередь это следствие, а не причина.
Вот именно. Длинная очередь говорит о кривой базе и запросах, а не проблемах в ВВ
...
Рейтинг: 0 / 0
10.01.2008, 11:34
| Ответить | Цитировать | Написать  
Производительность сервера
    #35052202
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
а /dev/sdb -- это tempdbs временный спейс? Если в нем толкаются сорт и хеш таблицы то надо DS_NONPDQ_QUERY_MEM 256 , потом можно еще увеличить если озу свободное останется
...
Рейтинг: 0 / 0
10.01.2008, 11:40
| Ответить | Цитировать | Написать  
Производительность сервера
    #35052235
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Журавлев Денис
LOG(100 000 000;16348) =~ 2
LOG(100 000 000;2048) =~ 2
Ступил.
В таблице 100 млн. записей, size ключа индекса 20 байт
LOG(100 000 000;16348/20) = 3
LOG(100 000 000;2048/20) = 4
...
Рейтинг: 0 / 0
10.01.2008, 11:48
| Ответить | Цитировать | Написать  
Производительность сервера
    #35052468
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
onstat-
1. Объединив все диски в один большой том вы потенциально сделали бутылочное горлышко в драйвере ОС.
когда iostat -x >iostat.log в поле avgqu-sz будет иметь значение больше 10 считайте что вы в него попали.
Поддерживаю. Поэтому я бы сделал несколько 10-х рейдов (как минимум два) и один уровня 0 (страйпинг) или просто пару отдельных дисков, на которые положил бы несколько tempdbs
onstat-
2. Уменьшив размер страницы до 2 К вы будете иметь потенциальную проблему с исчерпыванием количества страниц табличном пространстве.
Это значение ограничено приблизительно 16 000 000 страниц.
Когда они исчерпаются записи в таблицу вы добавить не сможете.
Я бы уточнил, что это ограничение на кол-во страниц в ОДНОМ ФРАГМЕНТЕ таблицы.
...
Рейтинг: 0 / 0
10.01.2008, 12:42
| Ответить | Цитировать | Написать  
Производительность сервера
    #35052572
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
DaugavaLRUS все равно не используется и если не трогать LRU_MAX_DIRTY, LRU_MIN_DIRTY использоватся скорее всего не будет.
Не понял выражения "LRUS все равно не используется".
Возможно, ты имел ввиду "LRU Writes" ?
Но я имел ввиду именно количество очередей LRUS, которое очень сильно даже влияет, особенно при таких больших объемах буферного пула. Ведь даже для поиска свободного буфера в цепочке из 100 тыс требуется значительно время и на это время вся эта цепочка буферов (очередь) будет залочена.
...
Рейтинг: 0 / 0
10.01.2008, 13:03
| Ответить | Цитировать | Написать  
Производительность сервера
    #35052600
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
DaugavaСтоит учесть, что с параметрами надо играться комплексно. Увеличив PHYSFILE без разбиения чанков, увеличения cleanears и игры с LRUS-ами, у вас получится скорее всего следующая ситуация. Общая производительность системы вырастет. Но появится проблема "длинный чекпоинт", во время которой запросы пользователей будут терпеливо ждать, пока он закончится.
Пусть эта проблема сначала появится :)
А бороться с ней можно другими способами, но уж никак не маленьким размером PHYSFILE.
На более старых версиях я наблюдал крах системы из=за переполнения физжурнала.
Подозреваю, что в новых версиях что то на эту тему сделали безопасней, но я бы не рисковал.
DaugavaУчитывая, что любый табличные операции вызовут простой системы, получаем, что без особого ущерба и длительной остановки все что можно сделать - выполнить советы Василия по temp-у. Ну и PHYSFILE, только не меняйте его слишком резко, помониторьте как изменятся чекпоинты (их частота и длительность).
Представленная статистика показывает, что КТ возникает каждые 2 (!) секунды, а физжурнал заполнен на 75%. Это очень не нормально и, возможно, именно КТ и являются одним из тормозов системы (посмотрите только на ckpwaits=2459 при numckpts=648).
Поэтому предлагаю увеличить PHYSFILE сразу и существенно, хотя бы до 200М.
Мониторить длительность КТ, конечно же, нужно.
...
Рейтинг: 0 / 0
10.01.2008, 13:10
| Ответить | Цитировать | Написать  
Производительность сервера
    #35052691
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
vasilisИз беглого анализа информации могу заметить:
- довольно странное (как для меня) соотношение usercpu и syscpu (78002.31 41276.13)
обычно на тех тяжелых системах, что я вижу, соотношение не ниже 80 к 20
Понял, откуда такое соотношение.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
Virtual processor summary:
 class       vps       usercpu   syscpu    total   
 cpu          7           8973 . 02     1640 . 55     10613 . 57 
 aio          6           0 . 00        0 . 04        0 . 04     
 lio          1           0 . 00        0 . 01        0 . 01     
 pio          1           0 . 00        0 . 00        0 . 00     
 adm          1           0 . 03        0 . 75        0 . 78     
 soc          1           380 . 33      3984 . 43     4364 . 76  
 msc          1           2 . 22        1 . 73        3 . 95     
 total        18          9355 . 60     5627 . 51     14983 . 11
По CPU оно как раз нормальное, а вот SOC для меня странный.
К сожалению, нет под рукой текущей статистики для Линукс-платформы, поэтому подскажите - это нормально, или может говорить о каких сетевых проблемах ?
...
Рейтинг: 0 / 0
10.01.2008, 13:32
| Ответить | Цитировать | Написать  
25 сообщений из 67, страница 2 из 3
  2  все
Форумы / Informix [игнор отключен] [закрыт для гостей] / Производительность сервера
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]