Оверхед по ресурсам жесткого диска

Question

[akhaustov]

Здравствуйте, коллеги!
Ситуация следующая: есть сервер с CentOS6 + OpenVZ
На сервере хардварный рейд на много террабайт.
В виртуалке на севере хранится видео-контент, который раздается nginx через псевдо-стримминг.
Когда пустили пользователей на ресурс, причем, небольшое достаточно количество, взлетела нагрузка на диск до 100%, что привело к жутким тормозам.
Экспериментами с nginx исправить ситуацию ощутимо не удалось, нагрузку снизили примерно до 85%
Об безысходности решили попробовать странную штуку: потушили контейнер, подняли nginx прямо на физической машине и рутовой директорией указали путь прямо внутрь потушенной виртуалки (/vz/private/1/srv/www/)

Нагрузка упала до 5-10% при такой же посещаемости.

Подскажите, пожалуйста, неужели OpenVZ дает такой оргомный оверхед по жесткому диску при высоких нагрузках на файловую систему?

Возможно ли это исправить? Виртуализацию хочется использовать все же.

Answer 1

[Otkrick]

диск виртуалки как делали? raw-data?

* ради интереса поставьте proxmox(это реально 10 минут) и попробуйте там создать виртуалку. ребята очень хорошо оптимизировали работу, допилили ядро… есть смысл посмотреть на реальный оверхед

Comments

[akhaustov]

Спасибо!
Попробуем.

Answer 2

[sHaggY_caT]

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

Comments

[sHaggY_caT]

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

[akhaustov]

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

Answer 3

[joneleth]

попробуйте bind mount

Comments

[akhaustov]

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

Answer 4

[Влад Животнев]

Кеширование в виртуалке в nginx для файлов выключено? Не через proxy pass они случайно отдаются?

Comments

[Влад Животнев]

debian.pro/328 вот тут подобное чинил я

[Otkrick]

предположительно, товарищ настраивал на хост-машине nginx также как и на виртуальной, поэтому вопрос в оверхеде openvz, а не настройке nginx

[akhaustov]

Именно так.
Отдаются без проксирования, в конфиге для домена только локейшены прописаны с указанием рутовой директории.

Answer 5

[Пума Тайланд]

У вас диск через simfs в openvz контейнере подключен.
В openvz точно нет такого оверхеда большого как вы говорите.

Comments

[akhaustov]

Вот и я удивлен.
Нужно попробовать перебрать все конфиги.

[akhaustov]

А могут ли влиять соседние виртуалки, даже если на них очень низкая нагрузка?
Всего виртуалок 5, под нагрузкой одна.

[Пума Тайланд]

Нет у меня около 15 виртуалок, на одной иногда раздаю файло через apache и таких проблем с производительностью не вижу, хотя и раздаю файло всего 100 мегабит.

У вас диск внутри как simfs?
посмотреть можно командой df -h

[akhaustov]

Да, как simfs.
В данный момент не могу зайти на сервер.
По памяти примерно так: /dev/simfs 12T xx xx 60% /
В числах могу ошибаться только.

Answer 6

[sHaggY_caT]

Можно ssh на эту машину в одной сессии screen с Вами, что бы не боялись, что я что-то Вам сломаю?

Comments

[akhaustov]

Извините, но не могу дать доступ.
NDA и все такое…
Пока решили вопрос отключением виртуализации.
Спасибо всем за советы и готовность помочь!

[sHaggY_caT]

Лучше ядро другой версии поставьте. Если не поможет, покажите, пожалуйста, ваши настройки контейнера.
Не может быть такого оверхеда в OpenVZ. это 99% что какая-то ошибка в конфигурации, и 1%, что баг в этой версии ядра, какая-то регрессия.

[akhaustov]

Ядро достаточно свежее 2.6.32-042stab076.5

Вот такой конфиг контейнера:

# UBC parameters (in form of barrier:limit)
# Primary parameters
AVNUMPROC="unlimited"
NUMPROC="unlimited"
NUMTCPSOCK="1801439850948198"
NUMOTHERSOCK="1801439850948198"
VMGUARPAGES="unlimited"
# Secondary parameters
KMEMSIZE="unlimited"
#TCPSNDBUF="2147483647:2147483647"
TCPSNDBUF="4611686018427387903:9223372036854775807"
TCPRCVBUF="4611686018427387903:9223372036854775807"
OTHERSOCKBUF="4611686018427387903:9223372036854775807"
DGRAMRCVBUF="unlimited"
OOMGUARPAGES="unlimited"
# Auxiliary parameters
LOCKEDPAGES="unlimited"
SHMPAGES="unlimited"
PRIVVMPAGES="unlimited"
NUMFILE="unlimited"
NUMFLOCK="unlimited"
NUMPTY="unlimited"
NUMSIGINFO="unlimited"
DCACHESIZE="unlimited"

PHYSPAGES="0:unlimited"
NUMIPTENT="unlimited"

# Disk quota parameters (in form of softlimit:hardlimit)
DISK_QUOTA="no"

ONBOOT="yes"

IP_ADDRESS="XXX.XXX.XXX.XXX"
HOSTNAME="vsXX.domain.ru"
NAMESERVER="127.0.0.1 8.8.8.8 8.8.4.4"

OSTEMPLATE="centos-6-x86_64"
ORIGIN_SAMPLE="our-template"

CAPABILITY="NET_ADMIN:on"
NOATIME="yes"

[sHaggY_caT]

1) Поставьте ядро другой версии

2) а зачем CAPABILITY=«NET_ADMIN:on»?

3) У Вас лимиты на шелл какие-то же стоят? Я про ulimit, а может и cgroups, В том числе шелл, под которым крутится nginx, если без контейнеров?
В Ваших настройках ограничений нет вообще никаких, поэтому вероятно, что nginx может разогнаться гораздо в контейнере OVZ сильнее, чем вне контейнера.

запустите контейнер с nginx с каким-нибудь конфигом из тех, что в комплекте идут, или простой пример с wiki.openvz.org

[akhaustov]

1) пробовали уже, стояло более старое ядро.
2) оно вродебы не должно влиять на данную ситуацию. Советуете отключить?
3) Попробуем. Спасибо!
Хотя, конфиг используется уже очень давно, а такая ситуация впервые возникла.