и еще парочка (может сильно напрячь накопитель))

#echo 600 >/proc/sys/vm/dirty_expire_centisecs
#echo 100 >/proc/sys/vm/dirty_writeback_centisecs

##echo 0 >/proc/sys/vm/dirty_ratio
##echo 0 >/proc/sys/vm/dirty_background_ratio

на 2.6.38 лучше не ставить «0» - просаживается сильно! хороший результат даёт «1»

> А это точно 12309? Визуально в такой сиутации систему убивает kswapd, тем более что записи на диск не происходит

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

> Зачитку данных из источника и запись на носитель параллельными DMA-трансферами

Откуда на SATA и USB параллельная передача?

Пока на USB пишут, с SATA читают следующую порцию.

А не: зачитали кучу данных, сбрасываем буферы и ждем, пока сможем зачитать другую кучу.

Что естественно приведет к падению скорости записи/чтения

Первое или второе?

По-моему, второе суммарно медленнее в силу вороха причин

Ну к примеру выставление

vm.dirty_background_bytes = 2M vm.dirty_bytes = 2M

снижает скорость записи на флешку до 12Mb/s :)

Transcend JetFlash U168 - одна из самых шустрых.

Погонял свою систему под разными нагрузками, особого влияния буферов записи на лаги не обнаружил. Скорее это больше похоже на общие проблемы планирования ввода-вывода: find / в 2 потока нагружает систему сильнее, чем dd if=/dev/zero of=hog.

Впрочем, у меня сильных лагов и не бывает, практически, если не делать tail /dev/zero.

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

Попробуй увеличить до 8—16. А еще можешь смонтировать флешку с -o sync и посмотреть _реальную_ скорость записи. Ну или через dd там. Я вообще там писал, что хорошо бы откалибровать размер буфера под оптимальную скорость записи, главное, чтобы он не был слишком большим и чтобы он был ограниченным как таковой.

Проблема в том, что если размер буфера не ограничивать, то ядро радостно использует под него все свободное на тот момент ОЗУ, что приведет не только к задержкам самой этой записи, но и к траблам при выделении памяти соседними процессами.

>планирования ввода-вывода: find / в 2 потока нагружает систему сльнее, чем dd if=/dev/zero of=hog

sync && dd if=/dev/zero of=/tmp/null bs={RAM/2}M count=1 & dd if=/dev/zero of=/tmp/2null bs={RAM/2}M count=1

седня еще потестил, пока вот так на 2.6.38

echo 32 >/sys/block/sda/queue/nr_requests
echo 2 >/proc/sys/vm/overcommit_memory
echo 100 >/proc/sys/vm/overcommit_ratio
echo 1 >/proc/sys/vm/dirty_ratio
echo 1 >/proc/sys/vm/dirty_background_ratio

> echo 2 /proc/sys/vm/overcommit_memory

Угу, теперь попробуй запусти VirtualBox или VMware

> Угу, теперь попробуй запусти VirtualBox или VMware

Запустил. ЧЯДНТ?

Запустилось, заработало, в толк не возьму, ЧЯДНТ.

Пиз...ть не мешки ворочать

00:00:31.165 ERROR [COM]: aRC=VBOX_E_IPRT_ERROR (0x80bb0005) aIID={09eed313-cd56-4d06-bd56-fac0f716b5dd} aComponent={Display} aText={Could n ot take a screenshot (VERR_NO_MEMORY)}, preserve=false

> dd if=/dev/zero of=/tmp/null bs={RAM/2}M count=1 & dd if=/dev/zero of=/tmp/2null bs={RAM/2}M count=1

В данном случае выделяется память, равная размеру ОЗУ, и, заполняясь данными из /dev/zero, вытесняет работающие приложения в своп. Было бы удивительно, если бы в таких условиях компьютер не тормозил.

Практически то же самое можно сделать, просто вызвав tail /dev/zero, что за несколько секунд сожрёт всю память.

А мужики-то не знают!

Я 3 месяца юзаю систему с overcommit_memory = 2, работаю с vbox и qemu, и тут мне внезапно анонимус пришел раскрыть глаза.

Ага, по 128Mb на виртуалку, и пускаешь там пинги. Гигабайтик выдели, да три копии запусти.

А ты своп включи.

Ты думаешь, в Apple работают отпетые идиоты, раз у них для отключения свопа даже крутилки нет?

Выключать своп оправдывается только в том случае, если ОЗУ всегда достаточно, и если выделение памяти предсказуемо на весь период аптайма. Эмбэддед какой-нить, например, где свое все, начиная от init'а.

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

> Ага, по 128Mb на виртуалку, и пускаешь там пинги. Гигабайтик выдели, да три копии запусти.

1 гигабайт с семерочкой внутри, ЧЯДНТ?

Лолище, а зачем ты выделяешь под ВМ больше памяти, чем может вместить реальное ОЗУ? ССЗБ?

> Гигабайтик выдели, да три копии запусти.

да три копии запусти.

Виртуалки обычно должны что-то полезное делать, а не бороться друг с дружкой за память. На локалхосте можно, конечно, все запустить и понаблюдать, что как-то оно запускается, прежде чем раком встать — чисто для демонстрации, что оно может.

На продакшене такой подход не катит.

>Угу, теперь попробуй запусти VirtualBox или VMware

небось, без свопа сидим, мсье? )) или вся ОЗУ сожрана под всякие непотребства? ссзб одним словом, у других то работает

>В данном случае выделяется память, равная размеру ОЗУ, и, заполняясь данными из /dev/zero, вытесняет работающие приложения в своп. Было бы удивительно, если бы в таких условиях компьютер не тормозил.

вот в этих условиях и можно более точно подкрутить производительность вверх.
сначала графическая подсистема фризится, музон через mpd играет без тормозов, закачка 1Mb/s идет дальше. в последующие запуски графика оттаивает по-немногу))

на последний момент лучшие результаты для 2.6.38 (без всяких там cgroup)

echo 32 >/sys/block/sda/queue/nr_requests
echo 2 >/proc/sys/vm/overcommit_memory
echo 100 >/proc/sys/vm/overcommit_ratio
echo «noop» > /sys/block/sda/queue/scheduler

тестировал $sync && dd if=/dev/zero of=/tmp/null bs={RAM/2}M count=1 & dd if=/dev/zero of=/tmp/2null bs={RAM/2}M count=1

Ты знаешь, у меня занятая память редко переваливает за ~700, когда случается «ступор» системы.

Спасибо

У меня были мелкие подтормаживания на полной загрузке I/O, думал, это вполне нормально, ничего не предпринимал, ибо всё равно это редко случается.

Сделал

root ~ # sysctl vm.overcommit_memory=2
root ~ # echo 2097152 > /proc/sys/vm/dirty_bytes
root ~ # echo 2097152 > /proc/sys/vm/dirty_background_bytes

и внезапно притормаживания исчезли совсем.

AMD64, 2.6.32, 3GiB RAM, свопа нет.