vsftp-снижение нагрузки на жесткие диски (как кешировать скачиваемые файлы в ОЗУ)

[156]

Имеется фтп сервер, настроен, работает, сеть гигабит, 40-68 мегабайт в секунду качает, на сервере 2 гига озу, будет 4 гига, а может и больше. Пока к серверу подключен один пользователь, все хорошо, но когда к серверу подключается 4-6 человек, каждый из которых качает по 100-200 гигов фильмов и музыки в обоих направлениях, то скорость падает до 200-400 килобайт в секунду у всех. Предположительно, жесткие диски читают небольшой кусок файла, может 2-3 мегабайта, потом головки переходят к следующему файлу, и так для всех пользователей по очереди. В итоге скорость падает, за сервером невозожно даже печатать текст, жестки диски постоянно щелкают шаговыми двигателями, короче мне это не кажется хорошим явлением. При этом памяти используется около 180 мегабайт, остальное ОЗУ свободно, свап файл вообще 128 килобайт. Что хочется- можно ли сделать так, что бы считывамые файлы сначала скачивались в ОЗУ большим куском, например мегабайт в 100-200, а потом спокойно из ОЗУ передавались фтп сервером, и жесткие диски при этом меньше изнашивались, комп меньше бы тормозил. И примерно так же сделать и для закачиваемых файлов.

[rm_]

Всё и так должно автоматически кэшироваться в файловом кэше.

При этом памяти используется около 180 мегабайт, остальное ОЗУ свободно

Вывод команды free приведите.

[156]

Оно кэшируется (это очевидно ) , но очень мелкими частями, поэтому головки жесткого диска постоянно бегают между файлами. Вывод покажу вечером. Но саму суть вопроса это не меняет- можно ли где то в систему подстроить размер кэша для файлов , которые качает фтп сервер?

[rm_]

подстроить размер кэша для файлов , которые качает фтп сервер?

Размер и так используется максимально возможный, исходя из общего объёма памяти и её части, занятой приложениями.
Для увеличения производительности можно попробовать покрутить настройку read-ahead для дисков, см. hdparm -a.

[Bluetooth]

Возможна, проблема в баге ядра - скорость работы системы в целом заметно снижается при активных дисковых операциях. посмотрите, занят ли процессор во время "падения скорости", если да - то можно, конечно, поковыряться с шедулером ядра, либо перевести все на фряху(ибо баг, насколько я знаю, не спешат исправлять)

[Devon]

Я не спец по vsftpd, но могу предложить, например, смонтировать /tmp в оперативку. Хотя это ненормально в любом случае, такая нагрузка на винты при таком смешном количестве юзеров.

Могу предложить поиграться с
anon_max_rate
local_max_rate
Дабы все кому не лень не рвали канал, и уж точно эти лимиты надо ввести.

[156]

Посмотрел вывод команды фри, значит так- всего ОЗУ 2 гига, из них 400 мегабайт занято, 1600 мегабайт свободно, по своп файлу, 6 гигов всего, 128 килобайт занято, остальное свободно. По предложнию поиграться с hdparm - почитал топики на форумах за последние два года, везде рекомендуют не трогать эту утилиту, так как она разрабатывалась очень давно для IDE винтов, и сейчас система уже сама выставляет оптимальные параметры, к тому же у меня фтп сервак, собран на сата дисках, объединённых в програмный раид-1, мне кажется, что применение этой утилиты в данном случае не целесообразно. Может как то увеличить объём памяти для процесса по умолчанию или что то в этом духе?

[rm_]

Посмотрел вывод команды фри, значит так- всего ОЗУ 2 гига, из них 400 мегабайт занято, 1600 мегабайт свободно, по своп файлу, 6 гигов всего, 128 килобайт занято, остальное свободно

Это испорченный телефон? Привести сюда вывод команды, а не словами его пересказать - сложно?

[156]

Сервер в одном месте инет за 70 км от него. Поэтому написал по памяти. Если это принципиально, то конечно, вечером приведу вывод команды free. Посмотрел команды anon_max_rate и local_max_rate , собственно простое зарезание трафика при объёмах в 100-200 гигов не есть хорошее решение проблемы. Вот нашел ещё команду trans_chunk_size, по умолчанию она равна 0, а так народ её выставляет в 8192 , а для чего она конкретно предназначена, найти не удалось, очень расплывчатое пояснение, как бы для сглаживания трафика.
Вывод команды free

serg@linux-h8zh:~> free
total used free shared buffers cached
Mem: 2033992 477800 1556192 0 1356 316292
-/+ buffers/cache: 160152 1873840
Swap: 5237136 0 5237136
serg@linux-h8zh:~>

[Frank]

Итого, занято программами: 466 МБ; занято под буфферы ввода-вывода: 156 МБ; занято под дисковый кэш: 1829 МБ.
Пояснение: не стоит суммировать цифры, т.к. часть памяти может числиться одновременно и как кэш, и как память процесса. Кэш-память, которая может быть отдана программам по первому требованию: 1519 МБ.

[156]

Так вопрос , как программу vsftp заставить брать эту память.

[rm_]

Так вопрос , как программу vsftp заставить брать эту память.

Итого, занято программами: 466 МБ; занято под буфферы ввода-вывода: 156 МБ; занято под дисковый кэш: 1829 МБ.

А она уже её взяла.

[skor]

Во время работы в dmesg ничего не пишется по поводу дисков?
Уверены что дело именно в рейде? А не в прерываниях на сетевухе к примеру?
Может стоит переделать рейд? 0? 5 (добавить чуток дисков)? Апаратный рейд-контроллер поставить?
Рейд 1 это зеркалирование, чтение быстрее, запись остается на той же скорости. А т.к. у вас обмен данными идет в обе стороны, то оба диска у вас регуляроно и одновременно дергаются на запись (в отличии от чтения, когда данные разным клиентам могут читаться с разных дисков).

[skor]

http://www.opennet.ru/base/sys/linux_performance.txt.html

[TuLiss]

Может стоит переделать рейд? 0? 5 (добавить чуток дисков)? Апаратный рейд-контроллер поставить?

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