HDD + SSD на одной машине

Это 12306, существование которой все линуксоиды отрицают. Проц висит в iowait, а ядро Линукса монолитное и не паралелится, вот и всё. Фундаментальная проблема Линукса. Для частичного решения можно порекомендовать хороший (рейд) контроллер.

Характерным признаком 12306 являлось не просто «тупит», а полная неработоспособность! Автору смотреть в сторону количества оперативной памяти и настроек буферов отложеной записи на HDD.

Вывод free в студию

Характерным признаком 12306 являлось не просто «тупит», а полная неработоспособность!

Это всё слова.

тупит» все, то что вне HDD

а ты уверен, что оно полностью вне hdd? а ты уверен, что просто не началась нехватка памяти? и хуже того, нет ли на этом самом hdd свапа

12309, лошара

Характерным признаком 12306 являлось

всё что угодно. это не технический термин, а хомячковый

http://screenshot.ru/upload/image/Ng7P http://screenshot.ru/upload/image/Ng7L

Это dedicated, vds или vps?

HDD примонтирован на далекий раздел только с медиа-файлами.

Dedicated. И в принципе проблему наблюдаю не первый раз (не на первом сервере).

Почему hdd, используемый только одним сайтом, так влияет на все?

То что с диска льют на полной скорости забивает сеть вот и кажется что сервер тормозит.

Сеть используется всего на 1/5 от доступной. По iperf можно выжать еще спокойно 800 Mbit/s.

А настройки sysctl дефолтные. Система Debian 7.

Проц висит в iowait,

CPU не может висеть в iowait, процесс может. И CPU не один.

Ты бы меньше 3.14здел.

И CPU не один.

Так ядро Линукс - монолитное, оно не может на одно CPU повесить хард, на другой - SSD. Пока хард не отдаст ядро, SSD будет ждать.

интересно а во фряхе так будет? там ж тоже ядро монолитное. выходит, что спасение заключено только в gnu hurd и os X так как они микроядерные?

И решений без смены железа, даже из серии «костылей», посоветовать не можете?

Пока хард не отдаст ядро

Э? хард держит ядро? Я всегда знал что к харду обращается DMA, а тут вон какое откровение.

Его решение будет — винда. Спорим?

В топку такое решение. Производительность вин ниже линукса.

Да и то что софта нужного на вин нету это тоже факт. По поводу OS X - возможно и помогло бы, так как тесты систем на OS X хорошо себя показывают. Вот только кто эту ось установит на сервер? Никто. Так что остается Linux, или на крайний случай FreeBSD.

Успокойся, ленин тупит/троллит, он же известный виндотроль-линуксхейтер.

Монолитное ядро не означает однопоточное.

монолитность ядра никак не мешает разносить разные его подсистемы на разные ядра, пиши ещё, иксперт

Так в чем тогда проблема по вашему?

если бы знали в чём проблема - её бы уже не было)

но не смотря на это все висит в ожидании.

Это о сайтах? Т.е. через http. A если по ssh зайти как себя ведет сервер/shell? dmesg смотрел?

http ip/domain Даже при запроса favicon.ico, который статически отдается nginx. Кстати в iotop только Nginx висит, 1-2 процесса.

По ssh проблемы не наблюдаю совершенно - влетает просто. load average: 2.93, 2.93, 2.81 Tasks: 212 total, 2 running, 210 sleeping, 0 stopped, 0 zombie Cpu(s): 3.0%us, 0.7%sy, 0.2%ni, 84.5%id, 11.0%wa, 0.0%hi, 0.5%si, 0.0%st

И ошибок никаких не наблюдается. При снижении нагрузки на HDD все летает снова. И как писал ранее, проблему наблюдаю не впервые, а железо и ОС были разные.

По ssh проблемы не наблюдаю совершенно - влетает просто

Что и требовалось доказать — система не тормозит.

Проверяй http-server и пр. фигню!

/thread

Я всегда знал что к харду обращается DMA, а тут вон какое откровение.

DMA всего лишь повышает скорость линейной передачи данных. Если хард держит IO под SEEK, например, DMA тут не поможет ничем.

монолитность ядра никак не мешает разносить разные его подсистемы на разные ядра

Так подсистема-то одна.

Монолитное ядро не означает однопоточное.

В общем случае - не означает. В случае Линукса, и двух дисков на одном контроллере - вполне себе означает. Список ядерных потоков Линукса не большой.

Разве установка нормального (рейд) контроллера с большим (расширяемым) кешем - это венда ?

Попробуй включить aio в nginx, если еще не. Или увеличить количество workers.

Изменение worker_processes, worker_connections, worker_rlimit_nofile не решает вопрос. Кстати вижу, что локальный запрос (curl из самого сервера) выполняется без задержки.

Блджад, как по-твоему на говеном сата-контроллере говеный линукс на RAID0 получает N-кратную скорость чтения/записи?

По твоей теории пока один диск не отпустит CPU/ядро, другие диски будут тупо ждать и скорость не превысит скорости работы одного диска.

Всё, закройся и не отсвечивай, достал тупить.

локальный запрос (curl из самого сервера) выполняется без задержки.

Еще раз: проверь загрузку сети. Если локальная сетевуха занята на 20% (200mbit/s), то не факт что до DNS такой же широкий линк.

Вот и соврал и решил вопрос. worker_processes 2 => 8 => 16 не изменяло ничего. Установил 32 и все полетело. Судя по всему нужно поставить и больше, пиковое время еще впереди. Ядер 4, 8 потоков. Логично ставить 8/16. Но как вижу мало.

Только вот load average: 12.58, 7.64, 5.02. Что будет дальше непонятно.

Долезло до load average: 19.91, 11.26, 6.55 и уже отклик ухудшается.

load avg раздели на кол-во vCPU и не ссы, мелочь пока еще

Или у тебя много клиентов или DDOS. В любом случае это не 12309 и не проблема системы (линукса).

Не ддос, пока LA 24. Сайт откликается по разному. В большинстве случаев быстро, только иногда задержка до 0.7 сек. Ранее думало до 2-3 сек. Понаблюдаю что будет дальше и сообщу.

Пока всем спасибо за участие.

И как результат приплыли туда, с чего и начинали. LA фиксировался на 29-30, отклик сайта 2-3 сек. Скорость локального ответа = внешнему теперь.

Блджад, как по-твоему на говеном сата-контроллере говеный линукс на RAID0 получает N-кратную скорость чтения/записи?

Только на линейных операциях. В случае большой загрузки (много SEEK-а) там будет содом и гомора. Убивать за Линукс софт рейд.

По твоей теории пока один диск не отпустит CPU/ядро, другие диски будут тупо ждать и скорость не превысит скорости работы одного диска.

А по твоей теории, Линукс софт рейд раскладывает каждый диск на своё ядро процессора, да ? Прелестно. И это я тут туплю, не ты. На самом деле, IO далеко не всегда для процессора длится столько, сколько реально выполняется в железе. Отдал команду на запись мегабайта одному диску, он пишет в фоне, отдал другому. Так и получается ускорение. Но когда возникает большая загрузка и жоский SEEK, это всё превращается в ужос.

Не работает CPU с дисками все время, DMA приносит данные с диска в RAM. SATA контроллер многоканальный, по каналу на диск.

SEEK вообще никакого отношения к системе не имеет, это свойство диска позиционировать головку и естественно не выдавать данных пока seek не закончится. Если будут сплошные seek'и, то и данные будут идти медленно и это не зависит от ОС.

Если будут сплошные seek'и, то и данные будут идти медленно и это не зависит от ОС.

Да. Но эта медленность данных не во всех ОС влияет на другие диски, а также, на отзывчивость GUI и пр.

Да. Но эта медленность данных не во всех ОС влияет на другие диски, а также, на отзывчивость GUI и пр.

1. В случае ТС'а нет влияния 100% загрузки hdd на остальную систему включая sdd.

2. Это не связанно с софт-рейд системой линукса.

3. Это следствие попытки выжать максимум производительности, если искусственно замедлить поток данных 12309 (проявляющийся не на каждой комбинации железа) исчезает. Хотя его наличие — минус, но не такой фатальный как ты пытаешься его представить.

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

Я раз что идет дискуссия, желательно бы более мирно =) По моей проблеме. Изменено: worker_processes 24; Возможно достаточно и 16.

Добавлено: sendfile_max_chunk 512k; # в блок статики (их 3 таких) aio on; directio 512; output_buffers 3 1m;

Результаты: - потребление канала выросло из 150 до 350 Mbit/s. - load average: 0.34, 0.45, 0.57 - отклик сайта минимальный - потребление оперативки nginx ~ 2GB.