Perfomance
Serguei I. Ivantsov
От каких параметров зависит сколько Informix кушает процессорных ресурсов.
При относительно небольшом количестве пользователей (6) CPU Usage=100% в NT
Task Manager-е. Правда система тоже не супер (K6-2-333, 128MB), но мне
кажется, что такого не должно быть. Если у кого-то есть соображения по этому
поводу, пишите, буду премного благодарен.
--
С Уважением,
Иванцов Сергей aka ManOwaR NT Lover
Petro Petin
"Serguei I. Ivantsov" <man...@niist.ntu-kpi.kiev.ua> wrote in message
news:8khacd$es2$1...@igloo.uran.net.ua...
> Привет!
>
> От каких параметров зависит сколько Informix кушает процессорных ресурсов.
> При относительно небольшом количестве пользователей (6) CPU Usage=100% в
NT
> Task Manager-е. Правда система тоже не супер (K6-2-333, 128MB), но мне
> кажется, что такого не должно быть. Если у кого-то есть соображения по
этому
> поводу, пишите, буду премного благодарен.
Наоборот, так должно быть. (Даже если у тебя работает всего 1
пользователь).
Это означает, что сервер не простаивает, а все процессорное время тратит на
выполнение задач.
Наверное нетрудно понизить приотет сервера методом ОС, но уверен ли ты, что
это то что тебе необходимо? :)
Средств управления нагрузкой на процессор у Информикса нет. Это задача ОС.
ППА
Serguei I. Ivantsov
Спасибо за ответ.
> Наоборот, так должно быть. (Даже если у тебя работает всего 1
> пользователь).
Любой сервер будет загружен на 100% даже если работает один пользователь?
Что-то я не понимаю.
> Это означает, что сервер не простаивает, а все процессорное время тратит
на
> выполнение задач.
> Наверное нетрудно понизить приотет сервера методом ОС, но уверен ли ты,
что
> это то что тебе необходимо? :)
Нет. Меня интересует не слишком ли много ресурсов процессора занимает
Informix. Может я че не так наконфигурил?
Например значение bufwaits в onstat -p равное 150 за полтора дня - это
нормально? Или значение lockreqs=1522415570. Данные берет практически только
из кэша 100%/96.7%. Откуда могут идти тормоза?
>
> Средств управления нагрузкой на процессор у Информикса нет. Это задача ОС.
>
> ППА
--
С Уважением,
Иванцов Сергей
dau...@kpb.ukrpack.net
без юзеров, например процессор загружен на 100% (но не информиксом :-).
>Нет. Меня интересует не слишком ли много ресурсов процессора занимает
>Informix. Может я че не так наконфигурил?
Весь вопрос в том, какие задачи выполняют твои 6 юзеров. Если они просто
висят в коннекте и давно уже закончили свои запросы, то однозначно, с
сервером не все в порядке.
>Например значение bufwaits в onstat -p равное 150 за полтора дня - это
>нормально? Или значение lockreqs=1522415570. Данные берет практически
только
>из кэша 100%/96.7%. Откуда могут идти тормоза?
bufwaits твой пренебрежимо мал. Вот с lockreqs действительно могут быть
проблемы, у меня при 96 дневном аптайме на прилично нагруженном сервере он
всего в двое больше твоего (хотя может он у меня уже зашкалил несколько
раз?). На мой взгляд здесь может крыться проблема в 100% нагрузке
процессора, хотя лечиться это не столько администрированием сервера,
сколько администрирование БД (page/row level locking) и наведением порядка
в приложениях.
>> Средств управления нагрузкой на процессор у Информикса нет. Это задача
ОС.
Средств нет, но повлиять настройками конечно можно. Например, серврер
может быть настроен на многопроцессорность, кроме того, там может
использоваться PDQ и т.д. Я честно говоря, не производил экспериментов
(тем более на NT), как в таком случае будет вести себя нагрузка на
процессор.
Regards, Igor.
Petro Petin
<dau...@kpb.ukrpack.net> wrote in message
news:396c8...@lira.kpb.ukrpack.net...
> >Любой сервер будет загружен на 100% даже если работает один пользователь?
> Не любой, а тот у которого узким местом является процессор. У меня даже
> без юзеров, например процессор загружен на 100% (но не информиксом :-).
Ну понятно, ты считаешь rc5.
А что касается узких мест, то их 2: процессор и диск. Всегда узким
местом будет одно из двух :)
ППА
Vasyl Shulzhenko
<dau...@kpb.ukrpack.net> wrote in message
news:396c8...@lira.kpb.ukrpack.net...
> >Любой сервер будет загружен на 100% даже если работает один пользователь?
Ты сам понимаешь, что это ерунда. Информикс сам по себе (без выполнения
задачи, поставленной ему пользовательским запросом или утилитой админа)
ресурсы не кушает, если не считать фоновые процессы типа btcleaner,
контр.точки и пр., которые просто являются следствием тех же
пользовательских задач, но отложенных по времени.
В данном случае твоя загрузка проца говорит просто о том, что для выполнения
конкретных запросов на конкретной БД (объеме данных) твой проц является
узким местом и является первым кандидатом на апгрейт.
Хотя может у тебя просто не сказевые винты (которые кушают проц) и слишком
много сортировок, к примеру.
> Не любой, а тот у которого узким местом является процессор. У меня даже
> без юзеров, например процессор загружен на 100% (но не информиксом :-).
Знаем чем, но не признаемся :)) Информикс у тебя только для маскировки
стоит, судя по твоему lockreqs :))
> >Нет. Меня интересует не слишком ли много ресурсов процессора занимает
> >Informix. Может я че не так наконфигурил?
> Весь вопрос в том, какие задачи выполняют твои 6 юзеров. Если они просто
> висят в коннекте и давно уже закончили свои запросы, то однозначно, с
> сервером не все в порядке.
>
> >Например значение bufwaits в onstat -p равное 150 за полтора дня - это
в принципе да, хотя все познается в сравнении dskreads pagreads bufreads
dskwrits pagwrits bufwrits
> >нормально? Или значение lockreqs=1522415570. Данные берет практически
> только
> >из кэша 100%/96.7%. Откуда могут идти тормоза?
> bufwaits твой пренебрежимо мал. Вот с lockreqs действительно могут быть
> проблемы, у меня при 96 дневном аптайме на прилично нагруженном сервере он
> всего в двое больше твоего (хотя может он у меня уже зашкалил несколько
Мне кажется, что это ни о чем не говорит :)) Точнее, говорит о том, что
система не стоит, а что-то интенсивно делает.
> раз?). На мой взгляд здесь может крыться проблема в 100% нагрузке
> процессора, хотя лечиться это не столько администрированием сервера,
> сколько администрирование БД (page/row level locking) и наведением порядка
> в приложениях.
>
> >> Средств управления нагрузкой на процессор у Информикса нет. Это задача
> ОС.
> Средств нет, но повлиять настройками конечно можно. Например, серврер
> может быть настроен на многопроцессорность, кроме того, там может
> использоваться PDQ и т.д. Я честно говоря, не производил экспериментов
> (тем более на NT), как в таком случае будет вести себя нагрузка на
> процессор.
Кстати, на НТ есть прекрасный инструмент Performance Monitor, которым можно
много чего увидеть, в том числе и кто куда забрал проц. Может НТ занята
только свопированием или фоновой дефрагментацией (как я видел в одном месте
:).
Может вопрос поставим немного по другому ?
Как на данном железе, данной БД и данном приложении выжать максимум, т.е.
заставить систему крутиться быстрее в целом. Но это имеет смысл
рассматривать тогда, когда производительность системы не устраивает
клиентов, а если проблема только в 100% загрузке проца, а система реагирует
на запросы удовлетворительно, то значит там уже кто-то поставил "коровку для
доения" :))
--
С уважением,
Василий Шульженко
Serguei I. Ivantsov
Какие можно сделать выводы по данному onstat -p ?
Informix Dynamic Server Version 7.31.TC5 -- On-Line -- Up 2 days
01:49:11 --
22336 Kbytes
Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
5571 29641 205996498 100.00 39208 91694 1214507 96.77
isamtot open start read write rewrite delete commit
rollbk
8347782 570091 1052680 1630197 358320 17393 5176 347291
11937
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 52653.17 2637.20 587 1174
bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
150 0 2697353680 0 0 3 35102 349376
ixda-RA idx-RA da-RA RA-pgsused lchwaits
135 0 422 557 22
> > >Любой сервер будет загружен на 100% даже если работает один
пользователь?
>
> Ты сам понимаешь, что это ерунда. Информикс сам по себе (без выполнения
> задачи, поставленной ему пользовательским запросом или утилитой админа)
> ресурсы не кушает, если не считать фоновые процессы типа btcleaner,
> контр.точки и пр., которые просто являются следствием тех же
> пользовательских задач, но отложенных по времени.
> В данном случае твоя загрузка проца говорит просто о том, что для
выполнения
> конкретных запросов на конкретной БД (объеме данных) твой проц является
> узким местом и является первым кандидатом на апгрейт.
> Хотя может у тебя просто не сказевые винты (которые кушают проц) и слишком
> много сортировок, к примеру.
Винты IDE-шные, но UDMA-шные, а по сему проца они не кушают - проверено. А
вот как определить чем именно занимается Informix я не знаю.
> Кстати, на НТ есть прекрасный инструмент Performance Monitor, которым
можно
> много чего увидеть, в том числе и кто куда забрал проц. Может НТ занята
> только свопированием или фоновой дефрагментацией (как я видел в одном
месте
> :).
Процессор занимается исключительно oninit-ом. Это видно из того же Task
Manager-а. В нем CPU Time oninit-а на порядок превышает CPU Time у Idle
процесса. График использования процессора имеет вид пилы. А если еще
поставить ISM_COMPRESSION=True, то и вовсе прямая линия под потолком :(
> Может вопрос поставим немного по другому ?
> Как на данном железе, данной БД и данном приложении выжать максимум, т.е.
> заставить систему крутиться быстрее в целом. Но это имеет смысл
> рассматривать тогда, когда производительность системы не устраивает
> клиентов, а если проблема только в 100% загрузке проца, а система
реагирует
> на запросы удовлетворительно, то значит там уже кто-то поставил "коровку
для
> доения" :))
Пока устраивает, но видимо скоро придется апгрейдиться или как-то
оптимизировать пользователей :)
>
> С уважением,
> Василий Шульженко
--
Иванцов Сергей
>
>
>
Vitaliy Bashtovy
Petro Petin wrote in message <96341751...@jet.ncc.icyb.kiev.ua>...
>
> А что касается узких мест, то их 2: процессор и диск. Всегда узким
>местом будет одно из двух :)
Да ?? А оперативка , системная шина и т.д.
Вобщем это лирическое отступление.
Далее итоги по гаданию на кофейной гуще, в informix есть чудная утилитка под
названием onstat где можно посмотреть хто чего делает .
К примеру onstat -g glo покажет скоко какой процессор жрет и т.д.
если syscpu для процессов cpu не меньше usercpu то дела не очень.
потом следуют
onstat -u
onstat -g ses
onstat -g sql
и далее по ману.
>
>
dau...@kpb.ukrpack.net
>> без юзеров, например процессор загружен на 100% (но не информиксом :-).
>Знаем чем, но не признаемся :)) Информикс у тебя только для маскировки
>стоит, судя по твоему lockreqs :))
тьфу-тьфу. Но на счет моего lockreqs я готов поспорить, сейчас я сравнил
данные onstat-ов -p за последние 12 часов (которые не отмечались какой-то
экстраординарной нагрузкой) и выявил, что значение lockreqs должно было
быть как минимум на порядок большим (порядка 20 миллиардов), тоже
относится и к значению bufreads, которое при екстраполяции должно было бы
показать около 30 миллиардов (сейчас чуть больше 3-х). Из чего я заключаю,
что значения всех подобных вещей хранятся в DWORD-e (беззнаковом 32-битном
integer) и его значение у меня просто переполняется. А я то глупый, никак
не мог в свое время осознать, почему временами падает %cached для read-a,
обычно он равен 0.00 ибо для 100% там просто нет места :-). Возможно про
это написано в RTFM, но я честно говоря не встречал. Судя по всему,
нормальные администраторы сурьезных систем, просто частенько (на кроне)
делают onstat -z и подобных проблем не наблюдают.
>Хотя может у тебя просто не сказевые винты (которые кушают проц) и
слишком
>много сортировок, к примеру.
Очень дельная мысль, я почему-то сразу не подумал о такой возможности (у
меня прочно в мозгах сидит аксиома сервер->scsi).
Regards, Igor.
Igor Zavgorodny
не 24-часовой рабочий цикл).
Рекомендую посмотреть onstat -g glo для детализации нагрузки.
>Винты IDE-шные, но UDMA-шные, а по сему проца они не кушают - проверено.
А
>вот как определить чем именно занимается Informix я не знаю.
>Процессор занимается исключительно oninit-ом. Это видно из того же Task
>Manager-а.
То что винт UDMA, еще не означает, что NT не использует процессор при
общении с ним, насколько я помню, птичка сия по default-у выключена :-(.
Кроме того, при интенсивном общении с диском, даже при включеной птице
может наблюдаться загрузка проца. Проще всего проверить, положив информикс
и покопировать файлики приличного размера туда-сюда :-). В TaskManager в
этом случае нагрузка приписывается именно приложению, осуществляющему
доступ к данным.
Regards, Igor.
Vasyl Shulzhenko
<dau...@kpb.ukrpack.net> wrote in message
news:396d6...@lira.kpb.ukrpack.net...
> >> Не любой, а тот у которого узким местом является процессор. У меня даже
> >> без юзеров, например процессор загружен на 100% (но не информиксом :-).
> >Знаем чем, но не признаемся :)) Информикс у тебя только для маскировки
> >стоит, судя по твоему lockreqs :))
> Откровенно говоря да, я за ним практически не слежу последние 2 года,
> тьфу-тьфу. Но на счет моего lockreqs я готов поспорить, сейчас я сравнил
> данные onstat-ов -p за последние 12 часов (которые не отмечались какой-то
> экстраординарной нагрузкой) и выявил, что значение lockreqs должно было
> быть как минимум на порядок большим (порядка 20 миллиардов), тоже
> относится и к значению bufreads, которое при екстраполяции должно было бы
> показать около 30 миллиардов (сейчас чуть больше 3-х). Из чего я заключаю,
> что значения всех подобных вещей хранятся в DWORD-e (беззнаковом 32-битном
> integer) и его значение у меня просто переполняется. А я то глупый, никак
> не мог в свое время осознать, почему временами падает %cached для read-a,
> обычно он равен 0.00 ибо для 100% там просто нет места :-). Возможно про
> это написано в RTFM, но я честно говоря не встречал. Судя по всему,
> нормальные администраторы сурьезных систем, просто частенько (на кроне)
> делают onstat -z и подобных проблем не наблюдают.
Кроме этого, они сбрасывают статистику за сутки в файлик и имеют затем
материал для анализа - не будет ли через месяц плоховато системе с данным
ростом ежедневной нагрузки ? или насколько изменило новое (переделанное)
приложение общую картину (может там неудачно выбрали уровень изоляции или
забыли установить блокировку таблицы на уровне строки или слшком большие
транзакции и из-за этого кол-во ожиданий ресурса другими приложениями резко
возрос и т.д.)
> >Хотя может у тебя просто не сказевые винты (которые кушают проц) и
> слишком
> >много сортировок, к примеру.
> Очень дельная мысль, я почему-то сразу не подумал о такой возможности (у
> меня прочно в мозгах сидит аксиома сервер->scsi).
>
> Regards, Igor.
--
С уважением,
Василий Шульженко
Vasyl Shulzhenko
> Привет !
>
> Какие можно сделать выводы по данному onstat -p ?
>
> 01:49:11 --
> 22336 Kbytes
>
> Profile
> dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
> 5571 29641 205996498 100.00 39208 91694 1214507 96.77
> isamtot open start read write rewrite delete commit
> rollbk
> 8347782 570091 1052680 1630197 358320 17393 5176 347291
> 11937
> 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 52653.17 2637.20 587 1174
> bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
> 150 0 2697353680 0 0 3 35102 349376
> ixda-RA idx-RA da-RA RA-pgsused lchwaits
> 135 0 422 557 22
По данной мизерной информации и выводы можно сделать мизерные :)
Например, что размер БД (меньше 20М) относительно маленький (по сравнению с
буферным пулом) и диски работают в основном на запись (при контрольных
точках и записи в физич. журнал). Для таких БД и таком кол-ве юзеров лучше
бы подошел ACCESS или FoxPro в сетевом варианте :))
Кол-во контр.точек какое-то большое - или идет круглосуточная работа (и
временной интервал остался по умолчанию 5 мин.) или часто контр.точка
стартует из-за заполнения физич.журнала, что более опасно и требует
настройки.
Вызывает удивление и кол-во откатов транзакций (>3%), видимо это специфика
прикладной системы - Уж не продажа ли билетов? :)) Но может быть просто в
приложении не стоит ожидание блокировок и откат транзакций происходит по
этой причине ?
Все же нужно поболее информации (onstat, onconfig, описание компа и
прикладной системы).
--
С уважением,
Руководитель учебного центра Софтлайн
Василий Шульженко
http://softline.kiev.ua/
Igor Zavgorodny
>материал для анализа - не будет ли через месяц плоховато системе с данным
>ростом ежедневной нагрузки ?
Ну я это и имел ввиду :-). Если уж быть до конца точным, то они (ох уж эти
ужасные админы) еще этот файлик и в БД запихивают, а самые вредные из них
вообще черпают данные из системных таблиц информикса :-)
Regards, Igor.
Serguei I. Ivantsov
> >
> > Какие можно сделать выводы по данному onstat -p ?
> >
> > Informix Dynamic Server Version 7.31.TC5 -- On-Line -- Up 2 days
> > 01:49:11 --
> > 22336 Kbytes
> По данной мизерной информации и выводы можно сделать мизерные :)
> Например, что размер БД (меньше 20М) относительно маленький (по сравнению
с
> буферным пулом) и диски работают в основном на запись (при контрольных
> точках и записи в физич. журнал). Для таких БД и таком кол-ве юзеров лучше
> бы подошел ACCESS или FoxPro в сетевом варианте :))
> Кол-во контр.точек какое-то большое - или идет круглосуточная работа (и
> временной интервал остался по умолчанию 5 мин.) или часто контр.точка
> стартует из-за заполнения физич.журнала, что более опасно и требует
> настройки.
> Вызывает удивление и кол-во откатов транзакций (>3%), видимо это специфика
> прикладной системы - Уж не продажа ли билетов? :)) Но может быть просто
в
> приложении не стоит ожидание блокировок и откат транзакций происходит по
> этой причине ?
> Все же нужно поболее информации (onstat, onconfig, описание компа и
> прикладной системы).
>
>
> С уважением,
> Руководитель учебного центра Софтлайн
> Василий Шульженко
Иванцов Сергей
Igor Zavgorodny
с
Хоть убей, я не пойму откуда взята цифра 20Мб? Или это результат какого-то
могучего расчета, оталкивающегося от Shared Memory (соотвественно кол-ва
буфферов) и попаданий в кеш?
>буферным пулом) и диски работают в основном на запись (при контрольных
>точках и записи в физич. журнал). Для таких БД и таком кол-ве юзеров
лучше
>бы подошел ACCESS или FoxPro в сетевом варианте :))
Я бы не был столь категоричен, в особенности, если людям важна целостность
их данных, а также преимущества клиент-серверной системы.
>Кол-во контр.точек какое-то большое - или идет круглосуточная работа (и
>временной интервал остался по умолчанию 5 мин.) или часто контр.точка
>стартует из-за заполнения физич.журнала, что более опасно и требует
>настройки.
Выступлю в качестве гадалки, ставлю на первое предположение. По цифрам
очень похоже.
>Вызывает удивление и кол-во откатов транзакций (>3%), видимо это
специфика
>прикладной системы.
Пожалуй, это единственное, что мне тоже попалось на глаза при
самостоятельном просмотре. Соглашусь, что это скорее специфика приложения.
Другое дело, как это может влиять на процессор?
Regards, Igor.
Igor Zavgorodny
>> Например, что размер БД (меньше 20М) относительно маленький (по
сравнению
Ура! Акела Василий промахнулся :-).
> Круглосуточная. А чем плохо большое кол-во контрольных точек?
В энциклопедии юных сурков сказано:
If you set CKPTINTVL to an interval that is too short, the system spends
too
much time performing checkpoints, and the performance of other work
suffers. If you set CKPTINTVL to an interval that is too long, fast
recovery
might be too slow.
>Как узнать из-за чего она стартует?
Посмотреть online.log
CKPTINTVL в onconfig по умолчанию установлен в 300 секунд. ИМХО у тебя он как раз
так и срабатывает.
(за 2 дня у тебя было всего 3 ckpwaits-a).
>А есть ли какие-то общие рекомендации самого Informix-а относительно
железа?
Вопрос с железом надо решать в каждом конкретном случае.
На счет рекомендаций Informix-a не знаю, но многие (пожалуй даже,
большинство) IT manager-ы забугорья, рекомендуют использовать для
Informix-a HP-UX.
Regards, Igor.
yurik shestakov
[...]
>> показать около 30 миллиардов (сейчас чуть больше 3-х). Из чего я заключаю,
>> что значения всех подобных вещей хранятся в DWORD-e (беззнаковом 32-битном
>> integer) и его значение у меня просто переполняется. А я то глупый, никак
>> не мог в свое время осознать, почему временами падает %cached для read-a,
>> обычно он равен 0.00 ибо для 100% там просто нет места :-). Возможно про
>> это написано в RTFM, но я честно говоря не встречал. Судя по всему,
>> нормальные администраторы сурьезных систем, просто частенько (на кроне)
>> делают onstat -z и подобных проблем не наблюдают.
VS> Кроме этого, они сбрасывают статистику за сутки в файлик и имеют затем
VS> материал для анализа - не будет ли через месяц плоховато системе с данным
VS> ростом ежедневной нагрузки ? или насколько изменило новое (переделанное)
VS> приложение общую картину (может там неудачно выбрали уровень изоляции или
VS> забыли установить блокировку таблицы на уровне строки или слшком большие
VS> транзакции и из-за этого кол-во ожиданий ресурса другими приложениями резко
VS> возрос и т.д.)
Кстати, я прикручивал вывод 'onstat -p' в MRTG. MRTG -- это такая тулза
для рисования графиков загрузки канала (и/или чего-то похожего) за
сутки, неделю, месяц и год. На графике может быть до 2-х параметров
одновременно. Я настраивал на сбор профиля раз в 5 минут. Эта тулза
накапливает лог по каждому параметру и учитывает сброс счетчиков.
Посмотреть можно здесь:
http://informix.com.ua/~yu/ix+mrtg/isam.html
Если кому интересно -- могу поделиться конфигами :-)
--
// yurik shestakov (aka shisha)
Vasyl Shulzhenko
Igor Zavgorodny <dau...@kpb.ukrpack.net> wrote in message
news:396dc...@lira.kpb.ukrpack.net...
> >Например, что размер БД (меньше 20М) относительно маленький (по сравнению
> с
> Хоть убей, я не пойму откуда взята цифра 20Мб? Или это результат какого-то
> могучего расчета, оталкивающегося от Shared Memory (соотвественно кол-ва
> буфферов) и попаданий в кеш?
Ну да, а от чего же еще ?
> >буферным пулом) и диски работают в основном на запись (при контрольных
> >точках и записи в физич. журнал). Для таких БД и таком кол-ве юзеров
> лучше
> >бы подошел ACCESS или FoxPro в сетевом варианте :))
> Я бы не был столь категоричен, в особенности, если людям важна целостность
> их данных, а также преимущества клиент-серверной системы.
Так я же пару смайликов поставил, вот таких :))
> >Кол-во контр.точек какое-то большое - или идет круглосуточная работа (и
> >временной интервал остался по умолчанию 5 мин.) или часто контр.точка
> >стартует из-за заполнения физич.журнала, что более опасно и требует
> >настройки.
> Выступлю в качестве гадалки, ставлю на первое предположение. По цифрам
> очень похоже.
Тут ты угадал, гадалкой будешь :)
> >Вызывает удивление и кол-во откатов транзакций (>3%), видимо это
> специфика
> >прикладной системы.
> Пожалуй, это единственное, что мне тоже попалось на глаза при
> самостоятельном просмотре. Соглашусь, что это скорее специфика приложения.
> Другое дело, как это может влиять на процессор?
Да никак... Был вопрос "Какие можно сделать выводы по данному onstat -p".
Вот я и отвечал.
А с процом вроде ясно - не тянет он...
Serguei I. Ivantsov
> > Вот так почитаешь Василия, и начинаешь чуствовать себя олигофреном :-).
Вот-вот. Правда я не знаю значения этого слова, но догадываюсь :)
> > Хоть убей, я не пойму откуда взята цифра 20Мб? Или это результат
какого-то
> > могучего расчета, оталкивающегося от Shared Memory (соотвественно кол-ва
> > буфферов) и попаданий в кеш?
>
> Ну да, а от чего же еще ?
А как это делается? Может я как то не так размер базы оцениваю - под эту
базу два чанка отведено, один из которых (100МБ) уже забит. (по onstat -d
free=2)
>
> > >буферным пулом) и диски работают в основном на запись (при контрольных
> > >точках и записи в физич. журнал). Для таких БД и таком кол-ве юзеров
> > лучше
> > >бы подошел ACCESS или FoxPro в сетевом варианте :))
> > Я бы не был столь категоричен, в особенности, если людям важна
целостность
> > их данных, а также преимущества клиент-серверной системы.
>
> Так я же пару смайликов поставил, вот таких :))
>
> > >Кол-во контр.точек какое-то большое - или идет круглосуточная работа (и
> > >временной интервал остался по умолчанию 5 мин.) или часто контр.точка
> > >стартует из-за заполнения физич.журнала, что более опасно и требует
> > >настройки.
> > Выступлю в качестве гадалки, ставлю на первое предположение. По цифрам
> > очень похоже.
Еще раз повторюсь - как узнать что контр. точка стартует из-за заполнения
физ. журнала. У меня в log-е только checkpoint-ы и logical log complete -
backup started - backup completed.
>
> Тут ты угадал, гадалкой будешь :)
:-)
>
> > >Вызывает удивление и кол-во откатов транзакций (>3%), видимо это
> > специфика
> > >прикладной системы.
> > Пожалуй, это единственное, что мне тоже попалось на глаза при
> > самостоятельном просмотре. Соглашусь, что это скорее специфика
приложения.
> > Другое дело, как это может влиять на процессор?
>
> Да никак... Был вопрос "Какие можно сделать выводы по данному onstat -p".
> Вот я и отвечал.
> А с процом вроде ясно - не тянет он...
>
Всем большое спасибо за участие. Вопрос снят, а вывод Василий написал двумя
строками выше. Интересно какое же надо железо для очень большого кол-ва
пользователей, например в инете?!
yurik shestakov
[...]
SII> Всем большое спасибо за участие. Вопрос снят, а вывод Василий написал
SII> двумя строками выше. Интересно какое же надо железо для очень большого
SII> кол-ва пользователей, например в инете?!
Определяется количеством одновременно обрабатыватываемых http-запросов.
Чем меньше -- тем лучше. С точки зрения желеха начинать можно от 128MB RAM.
В конфигурации SQUID (как http-accelerator), apache+mod_perl (до 30-40
запросов одновременно) + СУБД необходимый минимум будет уже 256MB RAM.
Процессор -- зависит от задачи. Самое узкое место -- объем RAM, затем
скорость системы ввода/вывода.
Vasyl Shulzhenko
> >> Например, что размер БД (меньше 20М) относительно маленький (по
> сравнению
> Ура! Акела Василий промахнулся :-).
Ух и злорадный :)
Я бы сказал в свое оправдание, что имел в виду активную часть БД, т.е. те
таблицы, которые в работе, а так пассивно-редко используемый размер может
быть и гигабайты.
> > Круглосуточная. А чем плохо большое кол-во контрольных точек?
Вот уж не видел у нас круглосуточные активно работающие системы...
И какие же это юзеры по ночам работают ? Таких, в принципе, немного :))
А для данного случая и режима работы такое кол-во контр.точек вполне
нормально.
Для аналогии я могу привести жизненный пример :).
Я работаю сутки и не кушаю, но когда я после такого голода сажусь за стол,
то ем долго и потом отдыхаю, т.е. час ко мне не подходи ( я не
работоспособен). А если я буду перекусывать каждый часик (кофе , булочка),
то и работать вроде могу (подходи с вопросами, но осторожно) и с голоду не
умираю.
В данном твоем случае, нормально в том же смысле, как и еда три раза в
сутки.
> В энциклопедии юных сурков сказано:
> If you set CKPTINTVL to an interval that is too short, the system spends
> too
> much time performing checkpoints, and the performance of other work
> suffers. If you set CKPTINTVL to an interval that is too long, fast
> recovery
> might be too slow.
>
> >Как узнать из-за чего она стартует?
> Посмотреть online.log
> CKPTINTVL в onconfig по умолчанию установлен в 300 секунд. ИМХО у тебя он
как раз
> так и срабатывает.
По количеству примерно и выходит, 12 раз за час, 288 за сутки.
> (за 2 дня у тебя было всего 3 ckpwaits-a).
А тут я не понял, что ты имел ввиду. Обычно ожидание контр.точки возникает
тогда, когда событие наступило (по времени или 75% заполнение лога или еще
ряд других), а начаться процесс не может, чаще всего из-за того, что одна из
транзакций находится в "критической секции кода" и сервер ждет ее
завершения.
> >А есть ли какие-то общие рекомендации самого Informix-а относительно
> железа?
> Вопрос с железом надо решать в каждом конкретном случае.
> На счет рекомендаций Informix-a не знаю, но многие (пожалуй даже,
> большинство) IT manager-ы забугорья, рекомендуют использовать для
> Informix-a HP-UX.
А какие могут быть рекомендации ? Есть рекомендации на инсталляцию, а на
систему как описать ?
Ведь сервер с базой в 2М с одним юзером м.б. так загружен, что и 4 ксеонов
не хватит, и наоборот, 10G базу может использовать 100 человек на
однопроцессорном пентюхе (если запрашивают минимум и редко :)
Чем лучше железо, тем веселее работает система и тем больше у тебя запас
мощности.
Igor Zavgorodny
>И какие же это юзеры по ночам работают ?
всю ночь идут бекапы и репликации (правда не Informix), а раз в минуту
собирается аккаунтинг с сетевых устройств (вот записей, 20-30 в минуту
даже ночью набегает :-).
Знаю я одних "индусов", так у них по ночам самая работа (кстати тоже без
юзера), засывается БД (порядка 400Мб) и всю ночь "колбасится" на предмет
разных украинских вкусностей, средняя ночная нагрузка - со среднедневной
не сравнить :-)
>> (за 2 дня у тебя было всего 3 ckpwaits-a).
>А тут я не понял, что ты имел ввиду..
Не удивительно, судя по всему я забыл отключить PDQ (в свой башке), когда
писал письмо. Я имел ввиду, что сервер не очень нагружен, т.е. количество
транзакций не велико и они весьма не продолжительны, если chkpoint-ы,
следующие как минимум раз в 5 минут, всего 3 раза натыкались на
незаконченную транзакцию, находящуюся в "критической секции кода" :-). У
меня подобных чекпоинтов - 52% от общего числа (правда в 7.22.UC2 IDS
могут быть совсем другие "критической секции кода", чем в 7.31.TC5).
Regards, Igor.
Igor Zavgorodny
не удалось его откомпилить на SCO (не нашел библиотеки, с помщью которой MRTG делает GIF,
проблемы с лицензионностью :-().
Заранее благодарен за скрипты, Игорь.
yurik shestakov
>>Кстати, я прикручивал вывод 'onstat -p' в MRTG.
IZ> Конечно интересно, кто же не любит графиков от MRTG :-). Жаль, мне так и
IZ> не удалось его откомпилить на SCO (не нашел библиотеки, с помщью
IZ> которой MRTG де лает GIF,
IZ> проблемы с лицензионностью :-().
http://frigate.kiev.ua/~yu/ix+mrtg.tar.gz
Кстати, новые версии MRTG юзают PNG, а не GIF. Так что можешь себе на SCO
насетапить. Если нужно, то могу и libgd подкинуть, к-я старая и еще
умеет делать GIF :-)
IZ> Заранее благодарен за скрипты, Игорь.
Vasyl Shulzhenko
> Кстати, я прикручивал вывод 'onstat -p' в MRTG. MRTG -- это такая тулза
> для рисования графиков загрузки канала (и/или чего-то похожего) за
> сутки, неделю, месяц и год. На графике может быть до 2-х параметров
> одновременно. Я настраивал на сбор профиля раз в 5 минут. Эта тулза
> накапливает лог по каждому параметру и учитывает сброс счетчиков.
> Посмотреть можно здесь:
> http://informix.com.ua/~yu/ix+mrtg/isam.html
>
> Если кому интересно -- могу поделиться конфигами :-)
А под НТ это работает ? И где посмотреть сам инструмент ?
Igor Zavgorodny
так просто настроить на мониторинг чего-угодно :-).
На SCO уже переносить не буду (проще наладить перенос результатов онстата
к МРТГе, чем пересетупливать акссесс-листы (а две МРТГ-и это уже занадто
:-).
Еще раз спасибо, Igor.
Igor Zavgorodny
> И где посмотреть сам инструмент ?
http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html
Regards, Igor.
yurik shestakov
IZ> Огромное человеческое спасибо. Я почему-то не задумывался, что МРТГу можно
IZ> так просто настроить на мониторинг чего-угодно :-).
IZ> На SCO уже переносить не буду (проще наладить перенос результатов онстата
IZ> к МРТГе, чем пересетупливать акссесс-листы (а две МРТГ-и это уже занадто
IZ> :-).
Главное -- уделить немного времени для ознакомления с
документацией [на MRTG] ;-)
IZ> Еще раз спасибо, Igor.
yurik shestakov
>> Кстати, я прикручивал вывод 'onstat -p' в MRTG. MRTG -- это такая тулза
>> для рисования графиков загрузки канала (и/или чего-то похожего) за
>> сутки, неделю, месяц и год. На графике может быть до 2-х параметров
>> одновременно. Я настраивал на сбор профиля раз в 5 минут. Эта тулза
>> накапливает лог по каждому параметру и учитывает сброс счетчиков.
>> Посмотреть можно здесь:
>> http://informix.com.ua/~yu/ix+mrtg/isam.html
>>
>> Если кому интересно -- могу поделиться конфигами :-)
VS> А под НТ это работает ? И где посмотреть сам инструмент ?
Да, работает и под NT. Ссылку посмотри на иконке "MRTG" на том URL,
что 6 строками выше ;-)