Сбор и анализ статистики загрузки UNIX системы  
  Побуждение  


Настоящие материалы являются авторскими, права автора защищены Законами РФ и международными соглашениями. Для использования настоящих материалов вам необходимо ознакомиться и полностью принять лицензионное соглашение. В случае, если вы не принимаете настоящее лицензионное соглашение полностью, вы не имеете права пользоваться настоящими материалами


Сбор статистики и анализ загрузки системы - эта тема зачастую не стоит на первом месте, и это обосновано массой решений, где возможностей UNIX серверов на современном, не таком уж и слабом, железе хватает за глаза без какого либо тюнинга системы. Поэтому зачастую администратор приходит к необходимости решения задач анализа статистики загрузки спустя какое то время

Зачем может потребоваться такая аналитика ? Должна быть причина, и, обычно, это не праздное любопытство администратора. Жалобы пользователей на медленную работу или недоступность сервисов, обоснование необходимости модернизации аппаратной части перед руководством, анализ потребностей при переработке IT инфраструктуры (например с модным сейчас использованием виртуализации), запросы служб технической поддержки сторонних производителей - малая часть побуждающих к проведению аналитики загрузки системы причин

Эта статья не претендует на исчерпывающую подачу материала, но опирается на реальный практический опыт автора, и призвана дать базовый материал, на основании которого заинтересованные лица смогут определить свои дальнейшие шаги


  Обзор утилит для сбора статистики  

UNIX предлагает несколько мощных утилит, позволяющих получить разнообразные данные о загрузке компонентов системы. На основе использования данных утилит возможно организовать сбор соответствующей статистики для проведения дальнейшей детальной аналитики

Одной из комплексных команд анализа является vmstat, запускаемой обычно с параметрами период_в_секундах и количество_повторов плюс модификаторы. Может работать в штатном режиме (без модификаторов), в режиме наблюдения за дисковой активностью (при достаточной версии ядра Linux), и в других режимах. Например vmstat 1 10 соберет и отобразит системную статистику за 10 последовательно идущих 1 - секундных интервала

Пример вывода:

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 1  0 651496  10704  54500 189868    0    0    15     5   12     0  5  1 94  1
 1  0 651496  10704  54500 189868    0    0     0     0 1005   768 45 55  0  0
 1  0 651496  10704  54500 189868    0    0     0     0 1005   724 46 54  0  0
 1  0 651496  10704  54500 189868    0    0     0     0 1005   778 50 50  0  0
 1  0 651496  10704  54500 189868    0    0     0    12 1011   713 47 53  0  0
 1  0 651496  10704  54508 189868    0    0     0    44 1012   755 48 52  0  0
 1  0 651496  10704  54508 189868    0    0     0     0 1015   783 46 54  0  0
 1  0 651496  10704  54508 189868    0    0     0     0 1016   740 46 54  0  0
 1  0 651496  10704  54508 189868    0    0     0     0 1010   760 48 52  0  0
 1  0 651496  10704  54508 189868    0    0     0     0 1007   721 47 53  0  0

Вывод отражает множество величин, в том числе использование процессора - в первом столбце (procs r) количество процессов в очереди за процессор, а также утилизацию процессора в группе "----cpu----", последовательно показывая процент утилизации пользовательскими процессами, системными, простой в ожидании ввода вывода и наконец процент незанятости процессора

Также отражаются данные по утилизации памяти, отраженные в первую очередь столбцом free группы "-----------memory----------", а также столбцом swpd, отражающим объем используемого swap пространства. Отличные от 0 величины явно говорят о нехватке оперативной памяти

Другие величины представлены группами "---swap--" "-----io----", отражающими активность и объем операций ввода/вывода для раздела подкачки и поблочный ввод/вывод дисковых накопителей соответственно, а группа "--system--" отражает количество прерываний и смен контекста

При запуске с модификаторами -d или -p partition_name vmstat отображает статистику вводы вывода дисковых накопителей - в общем, посекторном и комплексном разрезах для чтения и записи каждого накопителя либо каждой партиции каждого накопителя, а также отражает время операций - и может использоваться в комплексном анализе

Более информативно дисковый ввод/вывод отражает команда iostat (может и не поставляться с вашим дистрибутивом, для Linux обычно входит в пакет sar, о котором позднее). Данная команда также принимает аргументами интервал сбора статистики и количество итераций, а также модификаторы режима работы. Она может отображать данные утилизации процессора, но наиболее информативным является режим по умолчанию, отражающим статистику загрузки дисковых накопителей. Модификатор -x позволяет получить расширенную статистику в различных разрезах, а -p ALL позволяет отслеживать каждый раздел накопителя отдельно (параметры приведены для Linux, для Solaris есть некоторые отличия). Например команда "iostat -d -x 1 2" выдаст расширенную статистику утилизации дисковых накопителей. Статистика представляется отдельно для чтения и записи в посекторном, и покилобайтном разрезах, а также отражается количество отдельных и слитых обращений к устройству, усредненный размер обращений, время ожидания и обработки запросов, а также выводится процент утилизации устройства

Пример вывода:

Устройств: rrqm/s wrqm/s   r/s   w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
hda          0,13  12,93  1,86  4,78   27,30  141,74    13,65    70,87    25,44     0,18   27,05   1,61   1,07
sda          0,00   0,02  0,06  0,00    0,45    0,22     0,22     0,11    11,32     0,00   14,22   3,25   0,02
---
hda          0,00   0,00  0,00  0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00   0,00   0,00
sda          0,00   0,00  0,00  0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00   0,00   0,00

А при запуске команды в варианте "iostat -d -p ALL 1 2" можно получить статистику утилизации отдельных разделов накопителей, измеренной в блоках (согласно документации эквивалентно сектору в ядрах 2.4 и выше, обычно 1 sec = 512byte)

Пример вывода:

Устройство:        tps  Блок_чт/сек Блок_зап/сек    Блок_чт   Блок_зап
hda               6,64        27,30       141,72   71603760  371766686
hda1              0,00         0,00         0,00       3116       1238
hda2             10,87        15,71        77,50   41212130  203286592
hda3              0,11         0,31         0,61     815116    1587440
hda5              8,52        10,62        62,63   27858762  164300048
hda6              0,20         0,65         0,99    1711932    2591368
sda               0,06         0,45         0,22    1170516     587912
sda1              0,08         0,45         0,22    1170340     587912
---
hda               2,00         0,00       160,00          0        160
hda2             20,00         0,00       160,00          0        160

Комплексный сбор статистики позволяет организовать пакет sar, штатно входящий в поставку Solaris, а также некоторые дистрибутивы Linux. Как вариант, можно скачать исходные тексты и скомпилировать под свою ОС (кстати sar пользуется виртуальной ФС /proc). Sar также принимает параметры интервала и количества итераций с множественными модификаторами, позволяющими собирать разнообразную статистику, в т.ч. по утилизации процессоров, памяти, дисковых накопителей и сетевой подсистемы. Другой удобной возможностью является накопление статистики в двоичном файле с последующей выборкой в требуемых разрезах, что позволяет достаточно просто организовать сбор статистики путем периодического запуска sar из планировщика с сохранением результатов в двоичном файле

Примерам накопления статистической информации может служить команда "sar -o /tmp/stats.log -A 1 1", добавление которой в планировщик позволит собирать статистику с выбранной частотой. Для получения данных собранной статистики из двоичного файла необходимо при вызове sar указать, откуда брать данные модификатором -f имя_файла. Также есть возможность указать начальное и конечное время суммарной выборки. Например, для получения данных по дисковой активности из файла собранной статистики с отбрасыванием пустых значений можно дать команду "sar -f /var/log/sa/sa11 /tmp/stats.log -d -s 12:32:00 -e 12:42:00 | grep -v "0,00 0,00 0,00"

12:32:01          DEV       tps  rd_sec/s  wr_sec/s
12:33:01       dev3-0      4,13      0,53     47,53
12:34:00       dev3-0      3,93      0,67     46,71
12:35:01       dev3-0      6,66      1,05     75,39
12:36:01       dev3-0      9,44     38,83     97,55
12:37:01       dev3-0     14,40    492,59     64,56
12:38:00       dev3-0      5,45      1,75     68,79
12:38:33       dev3-0      3,94      0,49     49,97
12:39:00       dev3-0      5,63      0,88     74,24
12:40:01       dev3-0      7,37     14,20     99,00
12:41:01       dev3-0     23,45     16,13    329,68
12:42:00       dev3-0      4,44      0,68     56,03
Среднее:       dev3-0      8,85     63,06     99,15

Данные по утилизации процессора могут быть получены командой "sar -f sa11 -P ALL -s 12:32:00 -e 12:42:00"

12:32:01          CPU     %user     %nice   %system   %iowait     %idle
12:33:01          all     46,47      0,00     53,53      0,00      0,00
12:34:00          all     46,96      0,00     53,04      0,00      0,00
12:35:01          all     46,88      0,00     53,12      0,00      0,00
12:36:01          all     46,59      0,03     53,33      0,05      0,00
12:37:01          all     47,29      0,00     52,71      0,00      0,00
12:38:00          all     46,59      0,00     53,41      0,00      0,00
12:38:33          all     46,33      0,00     53,67      0,00      0,00
12:39:00          all     47,02      0,00     52,98      0,00      0,00
12:40:01          all     48,89      0,00     51,11      0,00      0,00
12:41:01          all     46,89      0,07     53,04      0,00      0,00
12:42:00          all     47,34      0,00     52,66      0,00      0,00
Среднее:          all     47,02      0,01     52,96      0,01      0,00

Данные по утилизации памяти и разделов подкачки могут быть получены командой "sar -f sa11 -r -s 12:32:00 -e 12:42:00". Здесь, однако, есть тонкость, касающаяся сбора статистики по использованию памяти на Sollaris. Дело в том, что в поставляемой с ОС Solaris версией пакета sar вывод данных о свободной памяти производится в страницах памяти, а не килобайтах, что может ввести в заблуждение. Для перерасчета в килобайты необходимо умножить полученное количество свободных страниц на размер одной страницы памяти. размер страницы памяти в ОС Solaris можно вывести с помощью команды ОС pagesize, которая отражает размер страницы в байтах (обычный размер страницы - 8Кб). Пример вывода данных по утилизации памяти:

12:32:01    kbmemfree kbmemused  %memused kbbuffers  kbcached kbswpfree kbswpused  %swpused  kbswpcad
12:33:01        12452   1015064     98,79     53172    165692   1380196    660048     32,35    128948
12:34:00        12132   1015384     98,82     53280    165764   1380196    660048     32,35    128948
12:35:01        11160   1016356     98,91     53488    165832   1380196    660048     32,35    128964
12:36:01         9748   1017768     99,05     54136    166560   1380196    660048     32,35    128964
12:37:01         2588   1024928     99,75     66860    164056   1380196    660048     32,35    128324
12:38:00         2288   1025228     99,78     67060    164140   1380196    660048     32,35    128324
12:38:33         2228   1025288     99,78     67100    164180   1380196    660048     32,35    128324
12:39:00         3556   1023960     99,65     66820    163500   1380196    660048     32,35    128204
12:40:01         2816   1024700     99,73     66092    164008   1380196    660048     32,35    128076
12:41:01        10580   1016936     98,97     64224    161624   1380196    660048     32,35    127924
12:42:00        10212   1017304     99,01     64476    161716   1380196    660048     32,35    127924
Среднее:         7251   1020265     99,29     61519    164279   1380196    660048     32,35    128448

Данные по утилизации сетевых интерфейсов могут быть получены командой "sar -f sa11 -n DEV -s 12:32:00 -e 12:42:00", причем существую также возможности по выводу дополнительной информации по работе сетевых интерфейсов (такой, как количество зафиксированных коллизий, отброшенных пакетов и т.д. Более детальную информацию по этим возможностям можно найти в документации по пакету sar)

12:38:00        IFACE   rxpck/s   txpck/s   rxbyt/s   txbyt/s   rxcmp/s   txcmp/s  rxmcst/s
12:38:33           lo      0,21      0,21     11,10     11,10      0,00      0,00      0,00
12:38:33         eth0      0,82      0,12     69,59      8,49      0,00      0,00      0,00
12:38:33         eth1     21,47     12,10   6806,73    897,88      0,00      0,00      0,00
12:39:00           lo      0,58      0,58     39,75     39,75      0,00      0,00      0,00
12:39:00         eth0      1,17      0,22     95,65     13,74      0,00      0,00      0,00
12:39:00         eth1     16,70     10,23   2805,59    770,73      0,00      0,00      0,00
12:40:01           lo      0,66      0,66     41,94     41,94      0,00      0,00      0,00
12:40:01         eth0      0,41      0,10     32,27      6,24      0,00      0,00      0,00
12:40:01         eth1     16,79     10,09   2826,56    727,36      0,00      0,00      0,00
12:41:01           lo      6,01      6,01   2578,39   2578,39      0,00      0,00      0,00
12:41:01         eth0      0,43      0,21     31,94     13,52      0,00      0,00      0,00
12:41:01         eth1     18,46     11,50   4020,22    852,43      0,00      0,00      0,00
12:42:00           lo      0,39      0,39     24,54     24,54      0,00      0,00      0,00
12:42:00         eth0      0,49      0,14     35,46      7,63      0,00      0,00      0,00
12:42:00         eth1     19,29     12,79   5302,95    935,49      0,00      0,00      0,00
Среднее:           lo      2,36      2,36    883,39    883,39      0,00      0,00      0,00
Среднее:         eth0      0,61      0,16     48,53     10,21      0,00      0,00      0,00
Среднее:         eth1     18,18     10,95   3946,81    806,74      0,00      0,00      0,00

Показанными примерами возможности sar не ограничиваются. Например, использование модификаторов -H -t позволяет изменить формат вывода утилиты для последующего эффективного распарсивания и добавления в СУБД, а множественные модификаторы предоставляют различные данные о работе системы, например скорость переключения контекста, статистику очередей ввода вывода, скорость создания новых процессов (в секунду) и т.п.

Утилитой, отражающей загрузку системы в реальном времени, является top (её аналог в Solaris - prstat). Top может быть настроена в некоторых пределах под конкретные нужды пользователя (интервал обновления, сортировки, отображаемые столбцы и т.д.). Еще одна довольно простая команда - free - позволяет получить данные об утилизации памяти и swap области, в т.ч. вести наблюдение за повторяющиеся интервалы. Также удобными утилитами являются netstat, позволяющий получить информацию по открытым сетевым сессиям и fuser, отображающая использующие указанный файл или сокет процессы. Команда ps позволяет отобразить данные конкретных процессов, в т.ч. время старта, время работы, используемую память, приоритет и т.п.

В целом описанный набор утиилт с теми или иными уточнениями работает на Linux, SUN Solarus и FreeBSD, и вполне себе может рабоать и на других UNIX системах. Т.к. задача обзора - показать утилиты для общего анализа загрузки системы, обзор не включает специфические механизмы получения детальной статистики (сетевые мониторы, средства отладки и профилирования приложений, управления приоритетом задач и т.п. Что то могло просто не попасть в обзор, но для получения результата - сбора статистики о загрузке основных подсистем UNIX системы - описанного должно хватить


  В методику проведения анализа статистик ОС UNIX  

Анализируется утилизация основных компонент системы с учётом взаимного влияния - CPU, RAM, пэйджинг (своп, раздел подкачки), I/O (подсистема ввода/вывода)

  • для анализа CPU используются базовые показатели: очередь за процессор, количество ядер, утилизация CPU системными процессами, утилизация CPU пользовательскими процессами, утилизация CPU ожиданием ввода/вывода, простой CPU как по суммарным показателям для всех CPU, так и в раскадровке по отдельным CPU. Опционально используются показатели частоты переключения контекста процессоров
  • для анализа памяти используются базовые показатели: общего объёма физической памяти, объёма разделов свопа, свободной памяти, утилизированной процессами памяти, утилизированной буферами памяти, утилизированной кешем файловой системы памяти, размера используемого свопа, скорости обмена с разделом подкачки в разрезах входящих и исходящих страниц
  • для анализа утилизации дисковой подсистемы используются базовые показатели: занятости подсистемы ввода/вывода, времени обслуживания, очереди запросов, скорости обмена для операций чтения и записи, характеристик шины и дисковых устройств, в частности максимальной скорости чтения/записи на последовательных операциях
  • для анализа утилизации сетевых интерфейсов используются базовые показатели скорости обмена по операциям приёма и отправки пакетов, скорости прохождения пакетов различного размера, количества ошибок доступности шины как показателя непроизводительной загрузки Ethernet

Большая часть параметров собирается штатным коллектором статистик UNIX - sar и может быть уложена в базу для последующего агрегирования и анализа с помощью моего авторского инструмента СтатОС БЕССТ, который, как и все мои авторские инструменты, максимально использует предоставляемые штатными утилитами возможности, дополняя их авторскими расширениями, востребованными в процессе работы

Для исследования CPU важно выверить размер очереди за процессор, который не должен превышать текущего количества ядер. В случае постоянного существенного превышения можно говорить о нехватке вычислительной мощности текущих CPU или же количества CPU в зависимости от характера прикладной нагрузки. Кроме того время простоя CPU, фактически показывающая запас вычислительной мощности, должно соответствовать определяемым требованиями к системе показателям. На мой взгляд в общем случае величина простоя должна составлять не менее 20 процентов для нагруженных систем. Конечно это общее правило, которое должно корректироваться текущей практической ситуацией

Высокий показатель утилизации CPU системными процессами при невысоком показателе утилизации пользовательскими процессами говорит о неоптимальной архитектуре. В частности автору приходилось сталкиваться со случаем, когда неоптимально написанное приложение проводило избыточное частое сканирование файловой структуры с большим количеством вложенных друг в друга каталогов и файлов, что обуславливало системную нагрузку около 60 процентов при 10 процентах пользовательской нагрузки. Общее правило говорит, что системная нагрузка должна быть незначительной, а основная часть нагрузки CPU должна приходиться на пользовательские процессы

Также большое время CPU, потраченное на ожидания ввода/вывода, говорит об утилизации дисковой подсистемы и требует дальнейшего анализа статистик утилизации дисковой подсистемы (подсистемы ввода/вывода, I/O)

Вместе с тем при фиксации большой нагрузки на CPU причина может крыться как в нехватке физической памяти, когда ресурсы CPU используются на дополнительные операции, обеспечивающие пэйджинг (активное использование свопа/раздела подкачки), и потому факт достаточности/недостаточности памяти должен быть учтён дополнительно и по возможности исключён

Анализ использования памяти должен учитывать несколько базовых постулатов. Менеджеры памяти UNIX устроены таким образом, что приложению отдаётся виртуальная память, состоящая из управляемых менеджером физической памяти и разделов подкачки. Приложение в общем случае получает виртуальныю память, и не может без дополнительных телодвижений со стороны администратора использовать только физическую память или только разделы подкачки. Операционные системы семейства UNIX стараются забрать под себя всю физическую память, поэтому часто бессмысленно смотреть на показатель количества свободной памяти на нагруженной системе, ибо физическая память, не занятая системными и пользовательскими процессами и буферами файловой системы, отдаётся под динамический кеш файловой системы. Это общее правило, из которого возможны исключения, например в случае, когда прикладная нагрузка не порождает динамичной работы с файловой системой. Ещё одним важным моментом является факт - менеджер памяти UNIX в общем случае использует небольшую часть раздела подкачки всегда, даже когда хватает физической памяти, выгружая туда давно неиспользуемые страницы физической памяти. Этот момент управляется как конкретной реализацией менеджера памяти, так и настройками ядра и особенностями конкретной ОС семейства UNIX, но очень часто можно видеть использование небольшой части раздела подкачки даже тогда, когда есть свободная физическая память

Поэтому при анализе утилизации памяти необходимо обратить внимание на сигналоьный показатель объёма свободной физической памяти и раздела подкачки, после чего посмотреть на показатели объёма памяти, отдаваемой под кеш файловой системы, а также на показатели скорости обмена с разделом подкачки. Если скорость обмена с разделом подкачки низкая или нулевая, даже при фиксации использования какой то части раздела подкачки, то можно говорить о том, что физической памяти хватает. Если же скорость пэйджинга (обмена страницами с разделом подкачки) высока, то можно говорить о том, что физической памяти не хватает и нужно предпринимать какие либо действия. В частности если большая часть физической памяти отдаётся под кэш файловой системы, это может быть связано с неоптимальной конфигурацией файловых систем под ту или иную прикладную нагрузку. Например в случае использования файловых систем UNIX для хранения данных БД Oracle необходимо отключать кеширование таких разделов (в AIX это поция монтирования cio, в Linux прямой опции нет, но можно попробовать выставить флаги монтирования noatime, снижающих системную нагрузку на файловые системы). Более детальный анализ утилизации памяти возможен не во всех операционных системах. В частности Linux позволяет просмотреть разделяемые сегменты, тогда как AIX показывает всё содержимое памяти в различных разрезах. Аналогов в Linux автор не нашёл

Подсистема ввода/вывода или же (в общем случае) дисковая подсистема анализируется на общем горизонте с помощью показателей сквозной утилизации (busy), времени обслуживания и очереди запросов на ввод/вывод. Важно понимать, что показатель busy означает разное в различных ОС. В частности для Linux этот показатель аналогичен времени CPU на ввод/вывод и приближение к 100 процентам говорит о проблемах в аппаратной конфигурации, тогда как в Solaris (8 и 9) и AIX показатель отражает утилизацию шины и даже при 100% загрузке не означает каких либо проблем. Хм, по крайней мере так было лет 6 назад :) Если я ошибаюсь, буду благодарен за поправку. В любом случае необходимо смотреть также на рост очереди запросов и среднее время обслуживания запроса. Принято считать, что сервистайм выше 100 - 150 миллисекунд для дискового массива является показателем нехватки его производительности на текущей прикладной нагрузке, а рост очереди является дополнительным сигнальным показателем нехватки производительности

В то же время дополнительная утилизация дисковой подсистемы может быть вызвана нехваткой физической памяти и активным пэйджингом. Такую ситуацию по возможности необходимо исключать, т.к. постоянная нехватка физической памяти вводит аппаратную конфигурацию во внештатный режим работы. Также важно, что современные ОС позволяют получить инфорамцию об утилизации дисковой подсистемы в разрезе по процессам, в частности для Linux такую информацию отражает утилита atop


  Cбор статистики и последующая обработка  

В общем случае задача проведения аналитики сводится к постановке, обуславливающей выбор методов сбора статистики, разработке технологии анализа, обеспечивающей получение искомого результата, собственно сбору статистических данных, их агрегированию и обработке, и выдаче заключения

В общем случае оптимальным можно считать решение, проводящее сбор требуемой статистической информации на основе описаных выше утилит с последующим парсингом и укладыванием этих данных в базу. Довольно заманчиво воспользоваться для этого только данными sar, но это не всегда может быть удобным. Например, в iostat довольно удобно отображается процент утилизации дисковых накопителей, определенные выборки по занятости сетевых сокетов получаются из netstat и т.п. Хотя для дежурного сбора статистики на серверах в целях текущего мониторинга sar вполне себе подходит, но и там он не дает полной информации. Например заполненность файловых систем и дескрипторов sar не отображает (для этого правильнее использовать утилиту df)

Таким образом реализация механизма сбора статистики должна являться комплексом периодически запускаемых с определенными параметрами утилит, программных модулей для обработки (распарсивания) получаемых данных и укладки их в таблицы БД, и, возможно, модули проведения анализа и построения отчетов. Методы практической реализации здесь разнообразны и зависят от квалификации и багажа наработок каждого конкретного администратора

Что касается технологии проведения анализа, то здесь важно принять во внимание зависимости подсистем друг от друга, чтобы не получить некорректных результатов анализа. Например высокая утилизация дисковых накопителей на фоне активного использования раздела подкачки и малых величин свободной оперативной памяти говорят не о необходимости модернизации дисковой подсистемы, но о необходимости расширения объема оперативной памяти. Другим примером может служить постоянная очередь за процессор на фоне большого количества пользовательских сессий, которое не обязательно говорит о необходимости модернизации процессоров - в зависимости от используемых приложений более правильным может оказаться внедрение многопроцессорной конфигурации. Впрочем, если используются ресурсоемкие прикладные решения, многопроцессорная конфигурация может не решить проблемы, и оптимальным будет именно апгрэйд процессоров на более мощные

Правильный выбор интервалов, за которые производится сбор статистики, также требует планирования. Если множество короткоживущих процессов - нормальный режим работы системы, то задание большого интервала может оказаться таким же бессмысленным, как измерение средней температуры по больнице. В то же время слишком малые интервалы приводят к необходимости их постоянной обработки, увеличивают объем собираемой ститистики и могут увеличивать нагрузку на систему

Таким образом, проведение анализа загруженности - задача, которая должна решаться с учетом потребностей каждого конкретного случая. Обзор же на этом завершен

(C) Белонин С.С., январь 2005 г.

(даты последующих модификаций не фиксируются)



     
   
   
    Нравится      

(C) Белонин С.С., 2000-2018. Дата последней модификации страницы:2018-01-09 13:25:29