|
|
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
Выбегалло"вместо 8 часов операция обработки массива данных идет в течении почти 24 часов." - откуда взялись эти 8 часов ? Вам так кажется, или оно и вправду раньше не тормозило ? В таком вот аксептеС 8 часами мутная история: производитель софта утверждает что на аналогичных задачах в других конторах характерное время 8 часов. Вытрясти конфиг и конфигурацию железа ни из кого пока не получилось - вот и бьюсь как рыба об лед. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Можно ли считать, что разница в 10 раз между выделенными числами - это результат того, что при выполнении запросов мало используются индексы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 08:50 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
Можно ли и есть ли смысл заставить Informix использовать не KIO, а AIO? -------------------------------------------------------------------------- IDS 9.40, Windows 2003 Server ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 11:24 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
СередаМожно ли и есть ли смысл заставить Informix использовать не KIO, а AIO? -------------------------------------------------------------------------- IDS 9.40, Windows 2003 Server Нельзя на Windows 2003 Server. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 11:44 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
Середа... Можно ли считать, что разница в 10 раз между выделенными числами - это результат того, что при выполнении запросов мало используются индексы?Включи сбор стат-ки по таблицам (TBLSPACE_STATS 1) и смотри в ppf по каким таблицам (какого размера) у тебя 4млн. сексканов. Дело в софте всегда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 11:45 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
Журавлев ДенисВключи сбор стат-ки по таблицам (TBLSPACE_STATS 1) и смотри в ppf по каким таблицам (какого размера) у тебя 4млн. сексканов. Дело в софте всегда.Очень извиняюсь: как включить сбор стат-ки по таблицам (TBLSPACE_STATS 1) и что такое ppf? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 11:53 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
Заранее извиняюсь, за заданные вопросы: Чемберлен СередаМожно ли и есть ли смысл заставить Informix использовать не KIO, а AIO? -------------------------------------------------------------------------- IDS 9.40, Windows 2003 Server Нельзя на Windows 2003 Server. Я так понял, что AIO использует gfd для ввода-вывода (их аж 235 штук), а KIO по числу VCPU (аж 4 штуки)... Вот и вопрос у меня: 1) Может тогда AIO все зарезать? 1.1) И gfd как-то убрать - все равно их статистика нулевая, а ресурсы поди жрут? 2) AIO может их сделать в колличестве близком к количеству gdf (235)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 11:58 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
Середа Журавлев ДенисВключи сбор стат-ки по таблицам (TBLSPACE_STATS 1) и смотри в ppf по каким таблицам (какого размера) у тебя 4млн. сексканов. Дело в софте всегда.Очень извиняюсь: как включить сбор стат-ки по таблицам (TBLSPACE_STATS 1) и что такое ppf?Сорри - с этим уже разобрался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 12:00 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
Исправленный пост. Заранее извиняюсь, за заданные вопросы: Чемберлен СередаМожно ли и есть ли смысл заставить Informix использовать не KIO, а AIO? -------------------------------------------------------------------------- IDS 9.40, Windows 2003 Server Нельзя на Windows 2003 Server. Я так понял, что AIO использует gfd для ввода-вывода (их аж 235 штук), а KIO по числу VCPU (аж 4 штуки)... Вот и вопрос у меня: 1) Может тогда AIO все зарезать? 1.1) И gfd как-то убрать - все равно их статистика нулевая, а ресурсы поди жрут? 2) KIO может их сделать в колличестве близком к количеству gdf (235)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 12:03 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
Середа Я так понял, что AIO использует gfd для ввода-вывода (их аж 235 штук), а KIO по числу VCPU (аж 4 штуки)... Вот и вопрос у меня: Не трогайте ничего. KIO асинхронно работает, послал запрос, уснул не дожидаясь ответа диска, все у вас правильно, и максимальная длина очереди >10 тоже ни о чем не говорит (неизвестно когда она была максимальной, а вдруг в момент сбора статистики или бекапа, а не в момент реальной работы). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 12:03 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Середа Я так понял, что AIO использует gfd для ввода-вывода (их аж 235 штук), а KIO по числу VCPU (аж 4 штуки)... Вот и вопрос у меня: Не трогайте ничего. KIO асинхронно работает, послал запрос, уснул не дожидаясь ответа диска, все у вас правильно, и максимальная длина очереди >10 тоже ни о чем не говорит (не известно когда она была максимальной, а вдруг в момент сбора статистики или бекапа, а не в момент реальной работы).Т.е. все что могло бы тормозить со стороны дисков отметаем сслылаясь на то что буферизация чтения/записи больше 97% (кстати бываю редкие моменты, когда эти показатели падают 67% на чтение в частности)? Далее остается исследовать откуда идет прямой перебор данных в таких количествах. Есть версия: индексы строились давно с филлфактором 90% и не перестраивались. Может ли быть, что 10% запаса исчерпались и индексы просто не валидны на сегдня? Как-то это можно проONSTATить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 12:07 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
СередаТ.е. все что могло бы тормозить со стороны дисков отметаем сслылаясь на то что буферизация чтения/записи больше 97% (кстати бываю редкие моменты, когда эти показатели падают 67% на чтение в частности)?Низкий уровень кеширования (67%) говорит о плохом приложении, о маленьком буфере (не ваш случай явно). Высокий уровень 97, 99 ни о чем ни говорит, при 99.99% все тоже может быть очень плохо. Но к скорости дисковой системы вообще отношения не имеет. Т.е. теоритически она может быть узким местом (ну раид5 софтверный), но практически вряд-ли. Т.е. скорее может быть ситуация -- сексканов огромных таблиц, ускорение дисковой системы конечно поможет, но реально надо лечить приложение. Середа Далее остается исследовать откуда идет прямой перебор данных в таких количествах. Есть версия: индексы строились давно с филлфактором 90% и не перестраивались. Может ли быть, что 10% запаса исчерпались и индексы просто не валидны на сегдня? Как-то это можно проONSTATить?Филлфактор на индескный/последовательный доступ не влияет. Вы похоже вообще не понимаете что это такое, не трогайте, и не надо ничего перестраивать (перестраивать индексы вообще не надо, потому что практически 99.99% это не поможет и не меняет ничего). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 12:20 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
И еще lockreqs/commit ~ 21 тыс довольно большое значение по моему. Тоже косвенно намекает на seqscans больших таблиц ну или случай очень необычного софта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 12:29 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
Журавлев ДенисФиллфактор на индескный/последовательный доступ не влияет. Вы похоже вообще не понимаете что это такое, не трогайте, и не надо ничего перестраивать (перестраивать индексы вообще не надо, потому что практически 99.99% это не поможет и не меняет ничего). FILLFACTOR specifies the degree of index-page fullness. A low value provides room for growth in the index. A high value compacts the index. If an index is full (100 percent), any new inserts result in splitting nodes. You can also set the FILLFACTOR as an option on the CREATE INDEX statement. The setting on the CREATE INDEX statement overrides the ONCONFIG file value. Т.е. index-page fullness - это полнота не в смысле заполнения страницы, а в смысле "полноты индекса"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 12:39 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
Середа Т.е. index-page fullness - это полнота не в смысле заполнения страницы, а в смысле "полноты индекса"?это именно полнота в смысле заполнения страницы индекса, при 100% страница расщепляется. Каким боком относится к вашим проблемам не понятно, видимо никаким. ЗЫ: Понятние полнота индекса -- мне не известно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 12:57 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
ISA мне про память: Код: plaintext 1. 2. Завтра буду на фирме - производителе софта буду их спрашивать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 13:01 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
СередаISA мне про память: Код: plaintext 1. 2. Тут сложно судить про запас. Есть R сегмент (используется в качестве кеша) тут будет практически всегда 0, сколько его ни корми, а есть V, если его не хватает инфоримикс прихватит еще сам, но при кол-ве поль-й один тут настраивать особо нечего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 14:16 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
Середа, вы не там смотрите. Общие настройки сервера вряд ли дают падение производительности в 4 раза, разве что при очень грубых ошибках типа очень маленького буфера, но у вас их не видно. Что смущает - так это 1.8М seq scan-ов за 7 часов работы. Явно не хватает где-то индексов. Вам надо а) убедиться что сеть не перегружена (процессор, по вашим словам, недогружен), б) окончательно убедиться что диски не перегружены и в) выяснить, какие запросы выполняются в течении этого самого 24часового процессинга и сконцентрироваться на самых долгих их них. Не помешает своими глазами увидеть тех самых клиентов, что выполняют за 8 часов, а то ведь может все проще, как в том анекдоте про " и вы говорите " ? В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 21:44 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
ВыбегаллоСереда, вы не там смотрите. Общие настройки сервера вряд ли дают падение производительности в 4 раза, разве что при очень грубых ошибках типа очень маленького буфера, но у вас их не видно. Что смущает - так это 1.8М seq scan-ов за 7 часов работы. Явно не хватает где-то индексов. Вам надо а) убедиться что сеть не перегружена (процессор, по вашим словам, недогружен), б) окончательно убедиться что диски не перегружены и в) выяснить, какие запросы выполняются в течении этого самого 24часового процессинга и сконцентрироваться на самых долгих их них. Не помешает своими глазами увидеть тех самых клиентов, что выполняют за 8 часов, а то ведь может все проще, как в том анекдоте про " и вы говорите " ? В таком вот аксепте Все разрешилось до боли просто. 1) Система БД+приложение действительно плотно использует доступ к данным не по индексам. 2) Что-там так закручено, что увеличение параметров RA_ бестолку. Сейчас стоит Код: plaintext 1. Код: plaintext 1. 3) Что самое криминальное: обновление статистики делается через систему приложения... и оказалось, что админ приложения просто "забил" на такую второстепенную операцию, как обновление статистики . Короче: всех упорядочил. Таперь стало, как они говорят лучше (почти хорошо). Думаю, может еще заняться самодеятельностью: поотлавливать запросы юзеров, посмотреть какие индексы в наличии и пообщаться с разработчиками если что-то накопаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2006, 11:14 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
Прошу прощения за задержку с ответом. Середа onstatПрипязка ВП к физическому процессору имеет смысл когда есть достаточное количество процессров. В этом случае можно получить прирост производительности за счет более оптималього использования кеша процессра. Рекомендуется иметь в системе минимум один физический процессор не привязаный к ВП. Код: plaintext Можно как-то не привязывать VCPU к реальным? Можете не привязывать. Не трогайте параметры связанные с AFFINITY и ничего привязываться не будет. На разных версиях я получал разные результаты. Гдето говорилось, что нельзя запустить виртуальный процессор если физический последний в системе. На другой версии у меня запускалось 3 привязанных процессора и еще 2 не привязанных, на 4 физических процессорах На каких конкретно версиях это было я не помню. В любом случае связь количества ВП и производительности нужно подбирать исходя из архитектуры вашего приложения. onstatРазмер страйпа имеет смысл только в случае если у Вас raid5. Середа Почему Вы говорите, что если не рэйд-5, то страйп не имеет смысл? Как я понял сис.админов в том устройстве на котором хранится база есть отдельные настройки типа биоса в которых этот самый страйп выбирается и в зависимости от его величины билдится массив. Кроме того эта же величина данных считывается за один раз из массива. В raid 5 при изменении данных на диске пересчитывается контрольная сумма по всему страйпу, не зависимо от того сколько страниц(informix pages) было изменено базой. То есть при размере страницы 2 к и размере страйпа 64к при изменении в одной странице данных будет пересчитана и переписана конрольная сумма по всему страйпу 64к. Raid10 умеет читать и писать не полными страйпами. По вопросу размера кластера я полностью согласен с выводами дейт. Я где то читал рекомендацию, что размер кластера по возможности должен быть равен размеру страницы базы данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2006, 14:46 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
Середа3) Что самое криминальное: обновление статистики делается через систему приложения... и оказалось, что админ приложения просто "забил" на такую второстепенную операцию, как обновление статистики . Ха, а я что советовал ? Именно проверить утверждения других людей :) vasilis СередаАпдейты статистики софт выполняет сам по расписанию, которое у них там как-то завязано с другими операциями. Т.е. можно считать, что статистика обносляется своевременно. А я бы так не считал, а проверил. Хотя бы элементарным запросом по sysdistrib или воспользоваться готовым, например этим ---------------------------------------------------- -- List Tables with Update Statistics and without ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2006, 19:02 |
|
||
|
Производительность сервера БД
|
|||
|---|---|---|---|
|
#18+
vasilisХа, а я что советовал ? Именно проверить утверждения других людей :)Да. Я посмотрел вышеобозначенным запросом что и как обновляет приложение. Следы последнего массового обновления заметны 18 дней назад и ни разу не наблюдается HIGH. Я знаю, что на базах под postgres обновление статистики у нас идет не раз в сутки - иначе тормоза. Короче, сижу и обновляю статистику сейчас.... Сам! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2006, 16:32 |
|
||
|
|

start [/forum/topic.php?fid=44&msg=33833953&tid=1608631]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
158ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 203ms |
| total: | 457ms |

| 0 / 0 |
