Если вас интересует совсем низкий уровень (то есть отладка конкретных затыков, вместо "общее состояние сервера"), то надо смотреть в сторону blktrace. Там можно видеть каждый запрос IO со всеми деталями (кто послал, сколько времени запрос обрабатывался и кем). Очевидно, что и latency там тоже видно будет. Но он не бесплатный в смысле производительности (по процессору и latency для операций), то есть держать на продакшене включенным я бы не стал.
Не существует метода (я не знаю такого) различить bus saturation (PCI, SCSI) и тормоза дисков. Точнее, различить их можно, если дисков много и есть простаивающие. Если тупят нагруженные диски, а простаивающие выдают нормальную производительность - это диски, если производительность распределяется между всеми одинаково и проседает - это шина. Различить PCI и SCSI вообще никак нельзя (ИМХО).
Дэн Иванов: latency дисковых операций к этому не имеет отношения. flight time показывает, сколько времени (а после перенормирования дельты к секунде - какую часть времени) диск был занят. То есть если утрировать, то это показать "busy". Если диск всё время выполняет какие-то операции, то он занят и дополнительные операции выполнять не сможет или будет выполнять их с большим latency из-за очереди. Так что в atop'е принцип простой - близко к 90+%, диск не справляется с нагрузкой. Ниже 30-40% - ок, меньше 10% - диск простаивает.
Смотреть величину лучше не на секундном интервале, а на интервале в секунд 10-20-30.
Всякие пики по латенси и прочие "мгновенные странности" так не увидеть, но принцип такой: если диск уже занят и приходит ещё одна операция, то она уходит в очередь (что плохо). Чем больше таких ситуаций в течение интервала времени (чем ближе к 100%), тем более занят диск.
Проблему с вирусами это решит? Одно время я думал, что проблему можно решить с помощью политик ограниченного запуска, но последние смешные варианты с «вирусными иконками» разубедили.
Алсо, большинство современных дистрибутивов (т.е. 3.2+) на большинстве железа взлетают ровно и без запинок (типа «поставить драйвера» и т.д.).
Да, но на pv_ops будет память неправильно считаться (т.е. считаться будет как считалась, но /proc/meminfo и free будет показывать чуть меньше, чем реально выделено домену).
Вот только не надо предлагать софт от циско. После того, как они аутсорснули всё программирование в Индию, качество программ у них начало падать с фантастической скоростью.
Да, в порядке. Впрочем, в крутых почтовых системах для таких засранцев выделяют отдельный сервер, задача которого обрабатывать «долголежащие письма» и не мешать обработке нормальных.
Ну, насчёт 4х раз я бы сильно усомнился. Современные SATA делают примерно 150 IOPS на random IO, так что сделать там же 600… Не верю. Даже SSD'шки (intel 320) даёт в худшем случае 400 IOPS (ср. Intel 520 — 2000, но она стоит как пол-сервера 1 шт).
Я бы очень хотел посмотреть на VPS, которому прокинут AHCI/SAS контроллер по PCI. Другого метода дать прямой доступ к диску я не знаю. Даже если целиком диск отдаётся как phy, то он отдаётся как xenblk, то есть виртуальное устройство через кольцевой буффер. (Насчёт других систем виртуализации не знаю, но вероятнее всего, примерно так же).
Если же речь про контейнер класса LC/OpenVZ, то там нет никаких дисков, так как файловая система предоставляется из ресурсов хоста (уже как файловая система) и никто не даст пользователю контейнера возможность посылать что-либо в блочное устройство напрямую.
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
С большой вероятностью оно определяется как два PCI-E устройства, то есть общая полоса 10GT/s, что даёт потолок в 8Gb/s (восемь гигабит) с учётом 8/10 кодирования.
Софтовый миррор и не париться с драйверами. Если сам XCP на рейд перенести сложно. то уж из оставшегося места сделать миррор и вогнать его в lvm sr — элементарно.
не путайте Xen и XenServer. Кроме того, говорить, что зен в дебиане ставится «из коробки» — это мягко скажем, преувеличение. Пакеты — да. Дальше его пилить и пилить. XCP в этом смысле куда проще к развёртыванию, так же как и XenServer.
0) LSI говно. Я их терпеть не могу. Но если железка уже есть, с ней нужно жить.
1) Качаем ddk.iso с цитрикса. У XCP такое есть, для XenServer должно быть. Если нет — ставим центось, ставим хидеры той версии ядра, которая в dom0 у XenServer. Компилим модуль. Модуль перетаскиваем в dom0 XenServer'а.
Профит?
Кстати, а нахрена вам вообще рейд на хостах XenServer? Он же предполагает использование сетевого хранилища для адекватной работы миграции и прочих плюшек. Хостам рейд нужен постольку-поскольку.
У нас не амазоновская терминология. Виртуальная машина с настройками по-умолчанию (дебиан) включается примерно 5-7 секунд. (Понятно, что если накрутить сервисов, то машина хоть пол-часа стартовать будет). Реально время создания домена, загрузки ядра и его инициализации — около 3с. Ещё 2с грузится юзерспейс.
О том, как у нас считается потребление я как раз только что две статьи написал — как раз про память и процессор. (http://habrahabr.ru/company/selectel/). В кратце — будет считаться реально потраченное время процессора на обработку. С памятью — если задача простая, то вероятнее всего она уложится в минимальную память, то есть время работы * минимум памяти. Если будут всплески, то будет считаться площадь под кривой памяти.
duch.mimuw.edu.pl/~lichota/09-10/Optymalizacja-ope...