Solaris: углубленный мониторинг сервера базы данных

Если обнаруживается какое-либо "узкое место" (под которым в данном случае подразумевается ограничение производительности точно так же, как горлышко бутылки ограничивает течение жидкости в бутылку и из нее), то означает ли это, что все исследования на этом заканчиваются? Целесообразно в любом случае пройти весь процесс до конца, чтобы увидеть все возможные критичные показатели и проблемы производительности.
Однако следует иметь в виду, устранение одного "узкого места" может привести к выявлению других узких мест. Предположим, например, что система интенсивно ведет замещение страниц из-за нехватки памяти, но при этом никаких других проблем установить не удалось. Добавление памяти могло бы позволить улучшить производительность до отметки, на которой использование одного из дисков становится чрезмерным, в результате чего узким местом становится уже дисковая подсистема. Исследование дисковой подсистемы также могло бы обнаружить новые проблемы производительности.
Как только вы обнаружили и устранили "узкое место", повторите предлагаемый процесс исследования еще раз.
Наконец, является ли важным предлагаемый порядок проведения этапов исследования? Конечно, существует множество возможных путей для того, чтобы заняться мониторингом системы, но все-таки целесообразно проходить этапы исследования именно в предлагаемой последовательности.

Мониторинг памяти
Чтобы проверить, не является ли память "узким местом", следует воспользоваться утилитой vmstat, которая показывает,в том числе, что происходит с памятью в системе. Для целей оперативного мониторинга хорошим выбором является контрольный интервал в 5 секунд.
Вывод утилиты vmstat, представленный на Рисунке 1, демонстрирует систему, в которой не ощущается нехватки памяти:

             vmstat trace with no memory shortfall

Figure 1

 procs      memory            page           disk          faults       cpu

 rb w      swap free    re mf pi po fr de sr m1 m2 s6 sd in    sy   cs   us sy id

 08 0    3557104 1359368 0 621 0 0 0 0    0  00    0  0 417 11922  1190  12 2 86

 07 0    3555728 1358080 0 729 0 0 0 0    0  00    0  0 449 12797  1985  20 2 78

 59 0    3512184 1318120 0 3666 0 12 12 0 0  00    0  6 2198 32163 7404  70 10 20

 3 15 0  3485016 1293944 0 939 0 24 24 0  0  00    0  1 892 30760  2842  50 4 46

 0 18 0  3480520 1289912 0 813 0 0 0 0    0  00    0  1 616 27887  2895  31 4 65

 0 17 0  3476216 1285992 0 547 0 3 3 0    0  00    0  0 516 31687  1716  21 2 77

 1 16 0  3473000 1283232 0 542 0 6 6 0    0  00    0  0 663 43993  2112  30 3 67

 2 16 0  3469568 1280368 0 712 0 8 8 0    0  00    0  1 666 39791  3176  34 3 62

Рисунок 2 демонстрирует вывод vmstat на той же системе в случае нехватки памяти:

             vmstat trace with severe memory shortfall

Figure 2

 procs      memory            page            disk           faults    cpu

 rb w     swap  free re  mf pi po   fr   de   sr m1 m2 s6 sd in sy  cs us sy id

 0 31 0  2175384 47800 3 542 1 166 593 38656 141 0 0 0 1 689 26511  3549 19 4 78

 0 27 0  2170608 47552 2 790 4 305 1116 45208 269 0 0 0 2 711 36787 6050 27 6 66

 0 28 0  2168088 48704 4 788 1 190 432 47256 92 0 0 0 2 718 30558   3291 23 4 73

 0 29 0  2164592 47664 1 699 8 158 574 47712 136 0 0 0 1 777 29870  3400 19 3 78

 1 27 0  2162136 48184 2 734 9 140 403 42944 105 0 0 0 2 708 28258  3027 22 4 74

 1 27 0  2158560 47688 0 498 4 166 606 38656 146 0 0 0 1 750 41527  3034 20 4 76

 0 27 0  2155136 47408 1 489 6 240 796 38656 179 0 0 0 1 754 31926  3275 17 4 79

 0 27 0  2151664 47824 1 581 6 187 622 47712 145 0 0 0 2 946 36169  3741 19 5 76

На что следует обращать внимание
Прежде всего, обратите внимание на значения показателей po (pageouts - вытеснения страниц из оперативной памяти, количество килобайтов данных, вытесненных из оперативной памяти за секунду) и sr (scan rate - скорость сканирования, количество страниц памяти, отсканированных по алгоритму синхронизации). Когда эти показатели постоянно имеют высокие значения за один и тот же промежуток времени (например, значительно больше 100 (Кбайт или страниц соответственно) в секунду на системе с объемом оперативной памяти до 4 Гбайт, на более мощной системе это значение может быть больше), тогда возможно, что демон страниц вынужден скрывать свободную память от выполняющихся процессов. Необходимо ли увеличить объем памяти в этой системе? Возможно, что да.
Однако увеличение памяти может и не помочь. Это могло бы показаться полной бессмыслицей, но к сожалению, здесь не все так просто. Для прояснения ситуации потребуются некоторые дополнительные пояснения.
Pageouts (вытеснения страниц из оперативной памяти) могут присходить по целому ряду причин, включая следующие:

• "Грязные" (измененные) страницы файловой системы сбрасываются на диск. Такое опорожнение является нормальным и не создает проблем. Если файлы базы данных размещаются в файлах файловой системы, следует ожидать появление этого вида вытеснения страниц.
  
• Страницы памяти приложения выталкиваются на устройство своппинга (подкачки) для того, чтобы освободить оперативную память для других целей. Если рассматриваемые приложения являются активными или собираются стать активными, то замещение страниц - это плохо!
  
• Новая память была затребована некоторым приложением, и ему была назначена область подкачки. Эта ситуация также соответствует норме и не является проблемой.
  
• Страницы памяти были освобождены приложениями и выгружаются на диск. Не является ли замещение страниц пустой тратой времени, если память приложениям больше не требуется? Конечно, является! В Solaris 8 был введен новый флаг MADV_FREE системного вызова madvise(), который предназначен для того, чтобы разработчики могли сообщить операционной системе об отсутствии необходимости выгружать на диск такие страницы памяти.
  

Scan rate (скорость сканирования) представляет собой меру активности демона страниц. Этот демон активизируется и начинает искать страницы памяти для освобождения в том случае, когда какое-либо приложение не может найти достаточное количество в списке свободной памяти (память уменьшается до значения, задаваемого параметром lotsfree). Чем больший дефицит памяти, тем быстрее демон страниц будет сканировать страницы в основной памяти.
Основными портебителями памяти в системе являются:

• Приложения, включая текст (двоичный код), стек, который содержит информацию, относящуюся к текущей стадии выполнения программы и ее функциям, динмическую память, содержащую рабочую область программы, и память совместного использования.
  
• Страничный кэш файловой системы, который содержит ее данные; все блоки файловой системы на диске должны быть считаны в память до того, как смогут быть использованы. Этот кэш становится важным, когда файлы базы данных сохраняются в файловых системах.
  
• Ядро операционной системы.
  

Нормальное замещение страниц до Solaris 8
До выпуска Solaris 8 столбец free в выводе утилиты vmstat мог быть не слишком хорошим индикатором наличия доступной памяти в системе. Причина заключалась в том, что коль скоро страницы памяти используются страничным кэшем файловой системы, они больше не возвращаются в список свободной памяти. Наоборот, блоки данных файловой системы остаются в кэше на тот случай, если они снова понадобятся в будущем.
Когда демон страниц обнаруживает нехватку памяти и сканирует ее в поисках страниц, которые можно освободить, он вполне может выбрать для освобождения некоторые страницы из страничного кэша файловой системы. Если эти страницы были изменены, то они сначала опрожняются на диск. Не существует никакого простого способа для выяснения того, какая часть основной памяти используется страничным кэшем файловой системы в любой момент времени, но можно быть совершенно уверенным в том, что это будет существенно в том случае, если файлы базы данных расположены в файловых системах UFS, а не на низкоуровневых разделах. Установить размер памяти, используемой файлами UFS, поможет пакет memtool - инструмент мониторинга памяти, разработанный Ричардом МакДугалом.
Проблема состоит в том, что демон страниц может освобождать как страницы памяти прикладных программ, так и страничного кэша файловой системы, поскольку он не знает, к чему относится та или иная страница. Результатом могут стать интенсивное замещение страниц и серьезные проблемы с производительностью. Однако и добавление оперативной памяти не слишком поможет в данном случае. Это будет просто означать, что в памяти может кэшироваться большое количество страниц базы данных. К счасьтью, решение существует.

Приоритетное замещение страниц
Начиная с операционной системы Solaris 7, была добавлена новая функциональная возможность, которая называется priority paging (приоритетное замещение страниц). Эта возможность понижает в памяти приоритет страниц файловой системы таким образом, чтобы демон выбирал их для освобождения перед страницами прикладных программ. Такое поведение может коренным образом изменить проблему замещения страниц; приоритетное замещение страниц нужно разрешать везде, где базы данных сосуществуют с открытыми файловыми системами, особенно в тех случаях, когда файлы базы данных размещены в файловых системах.
Чтобы активизировать приоритетное замещение страниц, следует добавить следующую строку в конфигурационный файл /etc/system:

set priority_paging = 1

Доступны соответствующие патчи, позволяющие добавить функциональные возможности приоритетного замещения страниц к Solaris 2.5.1 и Solaris 2.6. Начиная с операционной системы Solaris 8, изменения в виртуальной памяти системы подразумевают, что приоритетное замещение страниц больше не требуется и не должно использоваться.

Файлы UFS и замещение страниц
Если файлы вашей базы данных представляют собой файлв UFS, а не низкоуровневые усторойства, то можно столкнуться с интенсивным сканированием страниц памяти, даже если было разрешено использование приоритетного замещения страниц. Фактически скорость сканирования может даже увеличиться, поскольку приритетное замещение страниц быстрее заставляет демона страниц становиться активным. Такое поведение представляет собой естественное следствие необходимости перенести все страницы базы данных в страничный кэш файловой системы UFS до того, как они смогут стать доступными. Продолжающаяся необходимость поисков свободной памяти влечет за собой ее постоянное сканирование на загруженных серверах, использующих файлы UFS.
Если приложение выполняет операции обновления, вставки и удаления данных, то следует также ожидать активизацию вытеснения страниц из оперативной памяти. Все операции записи базы данных также должны пройти через страничный кэш UFS прежде, чем может быть выполнена запись на диск. Хотя страница, записываемая на диск, могла быть предварительно считана в страничный кэш UFS, эта страница могла стать многократно используемой, если скорость сканирования высока. В этом случае страница должна быть повторно считана с диска до того, как сможет продолжаться операция записи на диск. Этот процесс, в свою очередь, замещает другую страницу памяти, и описанный цикл продолжается.
Как же можно остановить весь этот процесс замещения страниц? Чтобы исключить сканирование (при этом предполагается, что для ваших приложений вполне достаточно памяти), следует либо использовать низкоуровневые устройства, либо монтировать разделы базы данных с установленным флагом прямого ввода/вывода (forcedirectio).
Однако следует иметь в виду, что устранение страничной подкачки с помощью прямого ввода/вывода может не всегда приводить к мгновенному улучшению производительности. Страничный кэш файловой системы действует в качестве кэша второго уровня для страниц базы данных, и его удаление сразу же выявит любые несоответствия в размерах вашего буферерного кэша базы данных. Удостовертесь в том, что размеры буферного кэша базы данных установлены соответствующим образом; в противном случае можно столкнуться с ситуацией, когда в системе будет много свободной памяти, но при этом буферный кэш базы данных будет испытывать нехватку буферов.
Разрешение использовать прямой ввод/вывод для файлов базы данных и особенно для ее журналов может дать существенноые преимущества с точки зрения производительности, начиная с Solaris 8 1/01; более ранние версии прямого ввода/вывода могут не обеспечить существенного улучшения призводительности.
В заключение хотелось бы сделать следующее предостережение: хотя прямой ввод/вывод может оказаться очень полезным для файлов базы данных, не применяйте его для других файлов, не относящихся к базе данных, без тщательного предварительного исследования того, как он влияет на производительность системы.

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

Продолжение углубленного анализа
Если необходимо выяснить, на что расходуется память, существует ряд возможностей:

• Для окончательного ответа на вопрос о потреблении памяти следует воспользоваться утилитой memtool. Сценарий procmem, описанный далее, предоставит деьальную структуру использования памяти процессами.
  
• Выполните команду dmesg и взгляните на Avail mem (доступную память). Разница между доступной и физической памятью (для установления объема физической памяти воспользуйтесь утилитой prtconf или командой /usr/platform/`arch -k`/sbin/prtdiag) определяет объем памяти, зарезервированной для ядра операционной системы.
  
• С помощью команды /usr/ucb/ps -aux выясните, какие именно процессы являются основными "пожирателями" памяти. Эта команда выводит список сегментов памяти в процентах, используемой каждым процессом. Однако будьте осторожны! Указанная в этом списке память является виртуальной, а не физической, и вывод этой команды не слишком хороший индикатор того, сколько физической памяти фактически используется конкретным процессом в любой заданный момент времени.
  

Сценарий procmem требует, чтобы в системе был предварительно установлен пакет под названием memtool (Не поддерживается в Solaris 10 - Прим.sunhelp.ru), не вхлдящий в комплект поставки операционной системы, поскольку сценарий использует программу pmem (аналогичную стандартной программе pmap в Solaris, но с различными ошибками, зафиксированными в различных выпусках Solaris). Некоторые пользователи не желают устанавливать нестандартный пакет программного обеспечения на функционирующей системе, поэтому также доступна альтернативная версия, основанная на программе pmap. Сценарий procmem суммирует использование памяти для всех процессов и дает подробную информацию относительно использования резидентной,разделяемой для совместного использования и личной памяти. Пожалуйста, обратите внимание на то, что и сценарий procmem, и пакет memtool представляют собой неподдерживаемое фирмой Sun программное обеспечение.
Передача сценарию procmem параметра -h приводит к выдаче следующей информации об использовании памяти:

usage: procmem [-v] [-h | -p pidlist | [ -u username ] [ searchstring ]]

Examples:

procmem -p 10784 10759

       - show memory usage for processes with pids 10784 10759

procmem -u root

       - show memory usage for all processes owned by the root user

procmem -u "daemon root"

    - show memory usage for all processes owned by the root & daemon users

procmem netscape

       - show memory usage for process(es) in ’ps -ef’ with "netscape"

procmem -u fred netscape

       - show memory usage for "netscape" processes owned by fred

procmem

       - show memory usage for all processes (provided current user has

         superuser access privileges)

Definition of terms

  ’Kbytes’ is the total memory size of the process or file.

  ’Resident’ is that portion currently occupying physical memory.

  ’Shared’ is resident memory capable of being shared.

  ’Private’ is resident memory unique to this process or file.

  Resident = Shared + Private

Sizing



For reporting purposes, the ’Shared’ component has been counted once

only while the ’Private’ component has been summed for each process

or file. The /usr/lib shared libraries have been reported separately

since they tend to be widely used across applications. To be totally

accurate, though, the shared component of these shared libraries

should only be counted once across all applications, not once for

every group of applications. The same logic may apply to other

shared libraries also used by multiple applications.

Флаг -v предоставляет дополнительную информацию. Приведенный далее пример вывода procmem содержит данные по всем прцессам на некоем сервере Oracle.

Processes                 Kbytes Resident  Shared Private

---------                 ------ --------  ------ -------

Process Summary (Count)

  -csh (3)                  5376     2456    1064    1392

  -ksh (8)                 14624     2912    1456    1456

  automountd (1)            4088     3656    1792    1864

  cimomboot (1)             1576     1384    1256     128

  cron (1)                  1936     1744    1464     280

  devfsadmd (1)             2776     2536    1592     944

  devfseventd (1)           1272     1232     952     280

  dmispd (1)                3160     2648    1744     904

  dtlogin (1)               4920     2856    2192     664

  dwhttpd (2)              20080     7440    4496    2944

  esd (2)                  24712    21768    3880   17888

  grep (1)                   968      936     832     104

  in.ndpd (1)               1856     1488    1304     184

  in.rdisc (1)              1616     1416    1272     144

  in.rlogind (6)           10368     2464    1360    1104

  inetd (1)                 2648     2384    1384    1000

  init (1)                  1888     1608    1136     472

  iostat (1)                1824     1784     904     880

  ksh (5)                   9040     2320    1456     864

  lockd (1)                 1896     1656    1264     392

  lpsched (1)               3040     1768    1552     216

  mibiisa (1)               2952     2752    1504    1248

  mountd (1)                2952     2536    1528    1008

  nfsd (1)                  1888     1672    1264     408

  nscd (1)                  3200     2928    1528    1400

  ora_ckpt_bench (1)     1405264  1372488 1371824     664

  ora_dbw0_bench (1)     1406976  1374208 1371824    2384

  ora_dbw1_bench (1)     1406968  1374200 1371824    2376

  ora_dbw2_bench (1)     1406968  1374200 1371824    2376

  ora_dbw3_bench (1)     1406968  1374200 1371824    2376

  ora_lgwr_bench (1)     1405248  1372472 1371824     648

  ora_pmon_bench (1)     1405696  1372920 1371824    1096

  ora_reco_bench (1)     1405160  1372384 1371824     560

  ora_smon_bench (1)     1405192  1372424 1371824     600

  oraclebench (50)      70258944  1400768 1371824   28944

  powerd (1)                1632     1576     976     600

  rpcbind (1)               2584     2088    1296     792

  sac (1)                   1736     1488    1296     192

  sendmail (1)              2936     2280    1816     464

  sh (4)                    4176     1320     912     408

  snmpXdmid (1)             3744     3184    2024    1160

  snmpdx (1)                2144     1920    1520     400

  statd (1)                 2592     2208    1464     744

  syslogd (1)               4192     3008    1456    1552

  tail (1)                   968      936     792     144

  tee (2)                   1808      952     792     160

  tpccload (50)           418800    38944    3344   35600

  ttymon (2)                3464     1744    1336     408

  utmpd (1)                 1000      944     816     128

  vmstat (1)                1312       1280    808     472

  vold (1)                    2696       2408   1768     640

  vxconfigd (1)            14656      13944   1328   12616

  -----------------------------------------------------------------------------

  File (Count)                                            Kbytes Resident    Shared Private

  -----------                                             ------ --------    ------ -------

  /usr/lib Shared Library Totals                          291936       27928   2856   25072

  Other Shared Library Totals                            1473544       29304   7248   22056

  Mapped File Totals                                          560        488    488       0

  Binary File Totals                                     1378632       18864  13328    5536

  Shared Memory Totals                                  80280128 1360688 1360688          0

  Anonymous Memory Totals                                   89680      84008      0   84008

  -----------------------------------------------------------------------------

  Grand Totals                                          83514480 1521280 1384608     136672

Память совместного использования размером 1.3 Гбайт - большая часть из 1.5 Гбайт резидентной памяти, используемой на этом сервере, и одновременно основная часть, задействованная под процессы Oracle.
Сценарий procmem может применяться для того, чтобы сообщить о потреблении физической и виртуальной памяти всеми прцессами, которые содержат строку ora в выводе команды ps -ef (процессы Oracle обычно удовлетворяют этому критерию). Если в системе регистрируется другой пользователь Oracle, выполняющий те же самые приложения, то не следует ожидать увеличения значения компонента Shared памяти разделяемых библиотек /usr/lib, других разделяемых библиотек,двоичных файлов или сегментов разделяемой памяти. Можно ожидать увеличения компонента Private для разделяемых библиотек, отбражаемых файлов и анонимной памяти. Требуемая дополнительная личная память приблизительно равна общему количеству личной памяти этих приложений, деленному на текущее число пользователей.
Подробная информация доступна для всех прцессов, также как и итоговая сводная для разделяемых библиотек /usr/lib (которые обычно тспользуются многими процессами в системе, а потому при решении задач производительности должны учитываться только однократно), других разделяемых библиотек (например, разделяемых библиотек Oracle), отображаемых файлов (отображаемых в памяти файлов файловой системы), двоичных файлов (исполняемых программ), сегментов разделяемой памяти и анонимной памяти (динамической памяти и стека).
Сценарий procmem будет отображать точные сведения обо всей памяти, непосредственно используемой процессами, но не о памяти, принадлежащей файлам UFS, которые являются резидентными в страничном кэше файловой системы. Поскольку страницы файлов базы данных, хранящихся в файловых системах UFS, непосредственно не отображаются в адресные пространства процессов базы данных, они также не будут отображаться в итоговой сводке. Эту информацию предоставляет команда memps -m из пакета memtool: при этом требуется, чтобы был загружен модуль из memtool, который инсталлируется при первоначальной установке этого пакета.

Что можно сделать для того, чтобы уменьшить интенсивность страничной подкачки
Если вы используете файловые системы для хранения файлов базы данных, то первым шагом должно быть обновление операционной системы до Solaris 8 (или уже Solaris 9) или разрешение применять приоритетное замещение страниц на более ранних выпусках Solaris. В случае необходимости можно также рассмотреть возможность проведения следующих мероприятий, сокращающих проблемы с памятью на сервере:

• Добавить больше памяти в системе.
  
• Использовать прямой ввод/вывод для файлов базы данных.
  
• Сократить размер буферного кэша базы данных. Такое сокращение может привести к дополнительному вводу/выводу, но это почти всегда предпочтительнее замещения страниц, или страничной подкачки.
  
• Удалить приложения с сервера. Если приложения выполняются на сервере, переместите их на клиентскую систему и выполняйте эти приложения в режиме клиент/сервер. В результате должна освободиться память.
  
• Уменьшить количество пользователей в системе.
  

Мониторинг дисков
Если вы дошли до второго этапа, то должны точно знать, что происходит с памятью на вашей системе. Следующим этапом должно стать выяснение того, существуют ли какие-либо "узкие места" в дисковой подсистеме или диски, которые могут скоро стать "узкими местами".
Чтобы проверить наличие "узких мест" в дисковой подсистеме, следует воспользоваться утилитами iostat, statit или sar.
Попробуйте команду iostat -xn 5 (опция -n, отображающая дисковые имена в формате cntndn, доступна только начиная с Solaris 2.6). Если на вашей системе установлено много дисков, то вывод может быть таким огромным, что в нем даже сложно будет увидеть какой-либо смысл. Можно воспользоваться командой grep для того, чтобы удалить из вывода информацию о неактивных дисках (после проведения анализа того, почему в системе имеются бездействующие диски!):

iostat -xn 5 | grep -v “0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0”

Не пытайтесь ввести эту команду с клавиатуры - между всеми нулями требуется именно такие разделители, какие показаны в примере. Лучше просто извлечь показанную строку команды grep из вывода утилиты iostat и сохранить ее целиком для использования в будущем в файле под именем iostat2.
Если желательно сохранить отчет о работе дисков для дальнейшего использования, то для этого удобным форматом является формат двоичного файла, формируемого утилитой sar, поскольку в нем каждая точка данных имеет связанную с ней временную метку.

На что следует обращать внимание
Часть вывода утилиты statit, приведенная на рисунке 3, показывает поведение трех дисков. Первый диск используется полностью, третий - адекватно, а второй почти бездействует. Ключевой информацией являются показатели util% (использование диска в процентах) и srv-ms (время обслуживания в миллисекундах). Обратите внимание на то, что компонент "время обслуживания" (время, необходимое, чтобы завершить ввод/вывод на данном диске) имеет некорректное наименование. Фактически это время отклика диска, то есть время, взятое для завершения операции ввода/вывода из времени драйвера дискового устройства на хосте, включая эффекты организации очереди на контроллере и самом диске. Утилита iostat также выводит аналогичные значения: util% отображается как %b, а srv-ms - как svc_t.

            statit output for three disks

Figure 3

      Disk I/O Statistics (per second)

     Disk    util%    xfer/s rds/s wrts/s rdb/xfr wrb/xfr wtqlen svqlen srv-ms

     c2t4d2 100.0     137.4    133.8    3.7 4081    2048    0.00 12.34   89.8

     c2t4d3    0.3      1.0      0.0    1.0    0   14811    0.00   0.02  16.5

     c2t4d4   35.5     46.7     42.7    4.1 2048    2048    0.00   0.48  10.3

Для рабочих нагрузок OLTP, если использование диска постоянно превышает около 60% или время отклика постоянно превышает 35 миллисекунд, то вполне вероятно, что нагрузка на этот диск может негативно сказываться на производительности прикладных программ.
А вот для рабочих нагрузок DSS использование диска может превышать 60%, а времена отклика могут превышать 35 миллисекунд, и даже для единственного перемещения 1 Мбайт данных с диска емкостью 36 Гбайт может потребоваться 35 миллисекунд. Поле wtqlen на рисунке 3 (соответствует показателю wait в выводе iostat) сообщает, сколько других запросов ввода/вывода стоят в очереди и соответственно какая часть времени отклика связана с организацией очереди. Поле svqlen на рисунке 3 (соответствует показателю actv в выводе iostat) показывает количество запросов, покинувших очередь и активно обрабатываемых. Если длины очередей постоянно больше 1.0, а время отклика постоянно превышает 35 миллисекунд, то вполне вероятно, что нагрузка на этот диск может негативно сказываться на производительности прикладных программ.
Для обоих типов рабочих нагрузок ключевой проблемой является проверка того, насколько нагружены другие диски. Желательно избегать ситуации, когда некоторые диски будут нагружены, а другие будут простаивать. С этой точки зрения показатели использования дисков и времени обслуживания, показанные на рисунке 3, свидетельствуют об очень неудачном размещении данных на дисках.
Часть вывода утилиты iostat (команда iostat -xn 5) представлена в качестве образца на рисунке 4.

             iostat trace

Figure 4

                                    extended device statistics

         r/s  w/s    kr/s kw/s wait actv svc_t %w %b device

       33.2   0.0    66.4  0.0 0.0 0.6     18.4   0 25 c2t4d0

         0.0  2.4     0.0 27.8 0.0 0.0      1.7   0   0 c2t4d1

       60.2   0.0  120.4   0.0 0.0 1.2     19.4   0 48 c2t4d2

       53.8   0.0  107.6   0.0 0.0 0.6     11.8   0 26 c2t4d3

         4.0  0.0  254.3   0.0 0.0 0.1     13.5   0   5 c2t4d4

         0.0  1.2     0.0 19.8 0.0 0.0      2.6   0   0 c3t0d0

         0.0  5.6     0.0 54.4 0.0 0.0      1.9   0   1 c3t0d1

Использование дисков, показанное в этом выводе, как и в предыдущем случае, является несбалансированным, откуда следует, что необходимо внести усовершенствования в размещение данных на дисках.
Некоторые утилиты, такие как sar, например, сообщают имена дисков в формате sdn или ssdn, а не в формате cntndn. Выявив в системе диск с частыми обращениями к нему, может оказаться затруднительным определить вопрос по данному диску. Благодаря файлу /etc/path_to_inst можно преобразовать имя диска в формат, более пригодный для распознавания. Указанная процедура иллюстрируется далее.
Предположим, что в выводе утилиты sar на хосте pae280 обнаружен диск с именем ssd4. Прежде всего необходимо получить дополнительную информацию о диске ssd4.

pae280% grep " 4 " /etc/path_to_inst | grep ssd

"/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037e3d688,0" 4 "ssd"

Сложная строка, возвращаемая из файла /etc/path_to_inst (первая строка, заключенная в двойные кавычки), соответствует подробной информации для данного диска в дереве /devices. Элементы в каталоге /dev/rdsk (а также в каталоге /dev/dsk) фактически представляют собой символические ссылки на дерево /devices, поэтому мы можем выполнить поиск указанного выше элемента в каталоге /dev/rdsk:

pae280% ls -l /dev/rdsk/*s2 | grep \

“/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037e3d688,0"

lrwxrwxrwx   1 root root    74 Jun 27 18:43 /dev/rdsk/c2t1d0s2 ->

../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037e3d688,0:c,raw

Этот заключительный шаг показывает, что диск, соответствующий имени ssd4 - это /dev/rdsk/c2t1d0s2.
Можно использовать ту же самую процедуру, соответственно заменяя 4 и ssd на первом шаге. Возвращенная строка может быть после заменена строкой, начинающейся с /pci на втором шаге.

Продолжение углубленного анализа
Обратите внимание на то, что последние версии утилиты iostat имеют опцию -p, которая отображает статистику для каждого разделе диска. Эта опция может быть полезна в том случае, когда необходимо точно отследить, каое именно устройство базы данных ответственно за проблемы производительности.
Для систем, использующих Veritas Volume Manager, вывод информации по разделам является менее полезным, поскольку Veritas размещает все свои тома в разделе 4. Однако Veritas предоставляет программу vxstat, позволяющую провести мониторинг активности ввода/вывода для каждого тома. Эта программа является бесценной при проведении углубленного анализа и позволяет найти тома, связанные с интенсивным вводом/выводом, что особенно важно в тех случаях, когда несколько томов размещаются на одном и том же физическом диске.
Утилита vxstat может быть запущена следующим образом:

vxstat -g group -i interval -c iterations

где group - группа, interval - интервал мониторинга, iterations - количество итераций.
Будьте осторожны! В отличие от программ vmstat и iostat статистика, сообщаемая утилитой vxstat, предоставляет итоговые значения показателей за весь интервал, а не за секунду. Следовательно, необходимо разделить сообщенное количество прочитанных и записанных байтов на число секунд в интервале (чтобы получить количество прочитанных и записанных байтов за секунду) и также на 1024 (чтобы получить количество прочитанных и записанных килобайтов за секунду).

Что можно сделать, чтобы избежать "узких мест"
Чтобы преодолеть "узкое место" дисковой подсистемы, попробуйте применить один из предлагаемых способов:

• Расслоите данные, находящиеся на указанном диске, между несколькими дисками. Следует иметь в виду, что чем более широкий слой выбран, тем большее количество дисков будет подвержено воздействию отказа одного из дисков в пределах этого расслоения.
  
• Если на данном диске существует более одного тома базы данных, переместите один или несколько томов на другие диски.
  
• Увеличьте размер буферного кэша базы данных для того, чтобы попытаться уменьшить количество операций чтения с данного диска.
  
• Добавьте физические диски и дисковые контроллеры.
  

Эффективное размещение данных на дисках позволит избежать большинства "узких мест" дисковой подсистемы.

Мониторинг сети
После проверки оперативной памяти и дисковой подсистемы на предмет выявления "узких мест" остановите свой взгляд на любых сетях, соединенных с данным сервером. Хотя маловероятно, что "узкие места" в сети окажут непосредственное влияние на производительность сервера базы данных, они могут оказывать существенное воздействие на время отклика в приложениях.
Если приложения базы данных выполняются в режиме клиент/сервер, то медленная сеть между клиентом и сервером будет воздействовать на взаимоотношения между базой данных и прикладными программами. Если медленная сеть находится между приложениями и интерфейсом пользователя, то весьма вероятно, что с точки зрения пользовательского восприятия сервер базы данных покажется медленным.
На что следует обращать внимание
Простой способ определения воздействия времени задержки в сети на время отклика состоит в том, чтобы зарегестрировать время циклического маршрута, то есть, время прохождения от клиента до сервера и обратно пакетов, посылаемых утилитой ping, и построить соответствующий график. Следующая команда пингует хост adelaide через каждые 5 секунд и сообщает о времени прохождения циклических маршрутов в миллисекундах.

alpaca% ping -s -I 5 adelaide

PING adelaide: 56 data bytes

64 bytes from adelaide (129.158.93.100): icmp_seq=0. time=147. ms

64 bytes from adelaide (129.158.93.100): icmp_seq=1. time=150. ms

64 bytes from adelaide (129.158.93.100): icmp_seq=2. time=150. ms

64 bytes from adelaide (129.158.93.100): icmp_seq=3. time=150. ms

^C

----adelaide PING Statistics----

4 packets transmitted, 4 packets received, 0% packet loss

round-trip (ms) min/avg/max = 147/149/150

Некоторые прикладные транзакции влекут за собой многочисленные обращения к серверу базы данных, причем, каждое из них связано с издержками циклических маршрутов. Известны случаи, когда существенная доля времени отклика приложения объяснялась сетевыми задержками в глобальных сетях.
Один эффективный способ количественного определения времени отклика приложения в глобальной сети состоит в том, чтобы ввести фиктивную транзакцию с помощью эмулятора дистанционного терминала или браузера и измерять время отклика. Фиктивные транзакции могут вводиться с каждого дистанционного рабочего места через регулярные интервалы времени. Время отклика транзакций вместе со временем прохождения циклических маршрутов, зафиксированными с помощью утилиты ping, могут помочь определить, оказывает ли сервер или сеть существенное влияние на производительность.
Утилита netstat показывает активность пакетов в некоторй сети; пример использования этой утилиты приведен на рисунке 5.

            Network traffic on hme0

Figure 5

  alameda% netstat -i -I hme0 5

      input   hme0      output              input (Total)   output

  packets   errs   packets errs colls   packets errs    packets errs colls

  36717966 261164 25214401   12 187668 36718099 261164 25214534 12   187668

          2      0       1     0     0        2      0        1    0      0

Обращайте внимание, если количество конфликтов (показатель colls) составляет свыше 10% количества выходных пакетов (показатель output packets). Использование коммутаторов делает конфликты менее серьезной проблемой, чем раньше, когда множество устройств совместно использовали одну и ту же подсеть.
К сожалению, приведенный отчет утилиты netstat отображает лишь количество посланных и полученных пакетов, но не их размер. Без знания размера пакетов трудно оценить эффективную производительность сети.
Чтобы представить данные не только о количестве пакетов, но и о количестве байтов, переданных по сети, существует ряд доступных инструментов. Сценарий tcp_mon, который является частью инструментария SE, сообщает информацию сетевого траффика в пакетах и байтах. Ради простоты разделите теоретическую полосу пропускания сети на 10, чтобы получить эффективную пропускную способность сети в мегабайтах. Итак, производительность 10-мегабитной подсети Ethernet не превзойдет 1 Мбайт в секунду, а производительность 100-мегабитной подсети Ethernet - 10 Мбайт в секунду.
Недокументированная опция утилиты netstat, -k, сообщает о количестве пакетов, полученных и посланных каждым сетевым интерфейсом (соответственно ipackets и opackets). Начиная с Solaris 2.6, команда netstat -k сообщает также о количестве посланных и полученных байтов (соответственно rbytes и obytes). Утилита kstat, введенная в Solaris 8, позволяет избирательно извлекать сетевую статистику. Следующий пример отображает количество пакетов и байтов, посланных и полученных всеми сетевыми интерфейсами на хосте apollo.

apollo% kstat -p -s “*packets”

hme:0:hme0:ipackets 362997

hme:0:hme0:opackets 480774

hme:1:hme1:ipackets 0

hme:1:hme1:opackets 0

ipdptp:0:ipdptp0:ipackets 124649

ipdptp:0:ipdptp0:opackets 180857

lo:0:lo0:ipackets 45548

lo:0:lo0:opackets 45548



apollo% kstat -p -s “*bytes”

hme:0:hme0:obytes 394165502

hme:0:hme0:rbytes 47823373

hme:1:hme1:obytes 0

hme:1:hme1:rbytes 0

В приведенном примере представлены такие сетевые интерфейсы: два 100-мегабитных интерфейса Ethernet (hme0 и hme1), коммутируемое соединение по протоколу PPP (ipdptp) и интерфейс петли, или обратной связи (lo), предназначенный для кольцевой тестовой проверки. Приведенные численные значения являются совокупными; они представляют собой общее количество, начиная с последней перезагрузки системы. Вычисление средних размеров пакетов (rbytes/ipackets и obytes/opackets) показывает, что средний пакет, посланный через этот интерфейс, имел размер, равный 819 байт.
Хотя здесь основное внимание уделяется серверам баз данных, а не файл-серверам NFS, для полноты изложения следует отметить, что утилита nfsstat осуществляет мониторинг траффика NFS. На клиентской системе следует воспользоваться командой nfsstat -c. Во время работы сервера обращайте внимание на тайм-ауты, превышающие более чем на 5% вызовы, и на сообщения "not responding": они свидетельствуют либо о наличии сетевых проблем, либо о перегрузке файл-сервера NFS.
Начиная с Solaris 2.6, утилита iostat также показывает монтирования файловых систем NFS, поэтому вся дисковая статистика, доступная при использовании утилиты iostat, доступна также для монтирований NFS.

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

• Если проблемой становится сетевой траффик, установите несколько сетевых адаптеров и распределите сетевой траффик между несколькими подсетями. Подобное расширение сети обычно проще осуществить в случае локальной сети (LAN), чем в случае глобальной (WAN). Текущая технология локальной сети обходится относительно недорого и в большинстве сред обеспечивает приемлемую производительность. В сфере глобальных сетей уже доступны технологии, позволяющие удовлетворить даже высокие требования к пропускной способности, хотя глобальные сети все еще обходятся относительно дорого.
  
• Воспользуйтесь Solaris Bandwidth Manager, чтобы управлять сетевым траффиком на серверах со смешанными рабочими нагрузками.