>>91789
Чтобы он раздавал торренты, там даже I/O шедулер тюнить не надо – BFQ как раз запорет доступ в угоду тому, что не в фоне. А скорость чтения поднять – либо ставь диски в зеркало, либо качай их в конец винта, там удельная скорость чтения мегабайт/градус максимальная. Если хранилище, куда ты скачиваешь, никакое не хранилище, а самая настоящая файлопомойка – можешь поставить какую-нибудь нежурналируемую ФС или отключить/игнорировать журналирование через опции монтирования.

>>91792
Под торренты и файлопомоку у меня отдельный винт, скорость раздачи для меня не так важна, как скорость скачки. Я поставил nr_requests=8192 и back_seek_penalty=100, вроде стало лучше, но не сильно. Если сильно задрать dirty_writeback_centisecs то мгновенная скорость сильно подскакивает, но потом начинаются затыки, в результате средняя скорость только падает.

> нежурналируемую ФС или отключить/игнорировать журналирование через опции монтирования

Разве при диком количестве рандомных I/O, что генерирует торрент, оно даст заметный эффект?

>>91794

> скорость раздачи для меня не так важна, как скорость скачки

Гм, лично для меня скорость скачивания редко поднимается выше 2 МиБ/с. 5 МиБ/с – тем более редкость. Хотя я вроде не чёрт знает где живу. Поэтому такого, чтоб скорость скачки упиралась в дисковый ввод-вывод, у меня просто ещё никогда не было.

> nr_requests
> back_seek_penalty

Начнём с того, что первое хорошо работает, когда у вас реалтаймовый сервер, поставленный решить одну задачу. Тогда можно и noop вместо шедулера поставить, и пачками реквесты группировать. См. http://www.monperrus.net/martin/scheduler+queue+size+and+resilience+to+heavy+IO
http://yoshinorimatsunobu.blogspot.ru/2009/04/linux-io-scheduler-queue-size-and.html
Ну а насчёт второго – это, судя по документации, присущая только CFQ фича, и, если у тебя стоит CFQ, то становится понятно, почему от задирания nr_requests

> стало лучше, но не сильно

А учиытвая, что у тебя жестак стоит на потенциальном десктопе, то CFQ ещё и старается быть «честным» и впихивает в очередь запросы от других процессов, которые могут быть как на чтение, так и на запись, таким образом, стройного ряда запросов на запись не получается, отсюда и

> вроде
> Разве при диком количестве рандомных I/O, что генерирует торрент, оно даст заметный эффект?

Встречный вопрос – а почему не должно?

>>91796

> Гм, лично для меня скорость скачивания редко поднимается выше 2 МиБ/с. 5 МиБ/с – тем более редкость.

У меня проблемы начинаются где-то с 12МиБ/с.

> Начнём с того, что первое хорошо работает, когда у вас реалтаймовый сервер, поставленный решить одну задачу.

Собственно 99% нагрузки на этот конкретный винт - торренты, так что задача сходная.

> Тогда можно и noop вместо шедулера поставить, и пачками реквесты группировать.

Noop, насколько я понимаю, это простой FIFO, если его поставить то куча времени убьется на прыжки головки от начала диска к концу и наоборот из-за отсутствия группировки операций. Торрент же пишет сразу более чем в сотню мест на диске. Или я что-то не понимаю?

> впихивает в очередь запросы от других процессов, которые могут быть как на чтение, так и на запись, таким образом, стройного ряда запросов на запись не получается

Но жестак же тратит кучу времени на позиционирование головки, а не на переключение между чтением и записью.

> Встречный вопрос – а почему не должно?

Метаданные не меняются так часто, торрент ведь вначале забивает файлы нулями и только потом наполняет их содержимым. Во втором случае я не представляю что можно в большом количестве писать в журнал, кроме изменений mtime и atime, а это все равно чаще чем раз в секунду не сделаешь. Или же я ошибаюсь?

>>91797

> У меня проблемы начинаются где-то с 12МиБ/с

Даже для второго саташника самого по себе это приблизительно треть реальной пропускной способности. Ты hdparm’ом доступ к диску мерял?

> Собственно 99% нагрузки на этот конкретный винт - торренты

Откуда инфа? Тут надо список процессов смотреть и глядеть одновременно на iostat в течение некоторого времени, когда торрент ещё пишет на диск и когда разгонится.

> Noop, насколько я понимаю, это простой FIFO

Я вообще не представляю, как он работает. Но вон люди пишут, что с ним у них быстрее, они опыты ставили. Я предполагаю, что CFQ в их случае только всё портит, выстраивая очередь, поэтому отсутствие группировки позволяет пачкам запросов на запись скапливаться в ОЗУ по мере появления и лететь писаться на диск как только так сразу. Куда пишет торрент, зависит от политики ФС, как она распоряжается инодами, и вообще это уже другая песня.

> Но жестак же тратит кучу времени на позиционирование головки, а не на переключение между чтением и записью.

Там, по первой ссылке вроде чёрным по белому написано

> > As far as I understand, increasing the queue size has three effects: first it puts the pending requests into RAM (which is OK if you don't need to read after write or vice versa), second it augments the probability of merging requests and third it improves their ordering.

> Метаданные не меняются так часто

Журнал – это не только метаданные.

>>91800

> когда торрент ещё не пишет

*fftgj*

>>91800

> Даже для второго саташника самого по себе это приблизительно треть реальной пропускной способности. Ты hdparm’ом доступ к диску мерял?

Саташник первый, линейная скорость винта 30, для первого саташного интерфейса потолок - около 120 (1,5Гбит).

> Откуда инфа?

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

> Но вон люди пишут, что с ним у них быстрее, они опыты ставили

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

> Куда пишет торрент, зависит от политики ФС

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

> Там, по первой ссылке вроде чёрным по белому написано

Размер очереди и алгоритм ее обслуживания это несколько разные вещи, насколько я понимаю. Размер я до 8k задрал, может нужно больше?

> The NOOP scheduler is a simple FIFO queue and uses the minimal amount of CPU/instructions per I/O to accomplish the basic merging and sorting functionality to complete the I/O. It assumes performance of the I/O has been or will be optimized at the block device (memory-disk) or with an intelligent HBA or externally attached controller.

http://www.redhat.com/magazine/008jun05/features/schedulers/
Я же сильно сомневаюсь, что мой контроллер настолько умный, что сам умеет группировать запросы.

> Журнал – это не только метаданные.

Информации о том, что используемая мной xfs пишет туда что-то еще, я не нашел. Может плохо искал? Впрочем в любом случае журнал у нее не отключается.

>>91803

> не лежит там ничего системного

И всё равно упирается в дисковый ввод-вывод? Может, купить ему PCI контроллер поновее (а то и диски заодно)?

> но для меня куда важнее налить на винт больше данных за промежуток времени.

Ты хотя бы на картинки в блоге того японца смотрел? Там на графиках записи в БД миллионами пишутся.

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

При чём здесь потоки теперь?

> Размер очереди и алгоритм ее обслуживания это несколько разные вещи

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

> Размер я до 8k задрал, может нужно больше?

iostat и спроси.

> Может плохо искал?

http://ru.wikipedia.org/wiki/XFS

> Журналирование только метаданных (если не задать иное параметрами).

http://en.wikipedia.org/wiki/XFS#Performance_considerations

> XFS filesystems mount by default with "write barriers" enabled.

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

> to assure filesystem consistency, and its implementation is device specific

То есть, как бы данные вперёд, но с оговоркой по устройствам, но не сказано, каким. Странно. Барьеры в экстейшне работают на моих SATA II жестаках, и на любом андроиде, где они включены по умолчанию.

> To avoid this problem, where the data… is protected from power failure…, the filesystem should be mounted with the "nobarrier" option

Т. е. это можно отключить. Интересно, это тогда становится аналогом data=writeback или data=ordered в ext3/4?

> Filesystem writes are preceded by metadata updates to the journal, which can be a cause of disk contention.

Понятно, writeback. Ненадёжно (в случае поломки всё поломанное файло придётся перекачивать, это не восстановить), но быстро.

> …The feature, known as "delayed logging", increases the performance of metadata operations by many orders of magnitude, by pushing them almost entirely into memory.

А вот про эту штуку я в манах xfs вообще ничего не нашёл. Вообще, помнится мне, держали мы одну мускульную базку на xfs, опций тамошних я уже не скажу, помню только что быстрее экстейшнов она была где-то на четверть. Но это опять же от случая к случаю, ты б сам потестил разные ФСки с разными опциями, да посмотрел. Целесообразность применения ванговать бесполезно. Хотя я б поставил туда ext4 с BFQ и не парился. С продакшеновыми ФС дома только морока лишняя.

>>91805

> И всё равно упирается в дисковый ввод-вывод? Может, купить ему PCI контроллер поновее (а то и диски заодно)?

Контроллер куда новее винта и не самый плохой. А диски - я слышал что у современных дисков проблемы с временем произвольного доступа.

> Ты хотя бы на картинки в блоге того японца смотрел? Там на графиках записи в БД миллионами пишутся.

Разница между старым десктопным веником и 'SAS 15,000RPM, 2 disks, RAID 1' довольно существенная. И рейд у него явно не софтовый, значит и контроллер скорее всего с собственной памятью и планировщиком I/O.

> При чём здесь потоки теперь?

При том, что каждый из потоков качает произвольный кусок произвольного файла и пишет его на винт. Торрент же.

> Очереди ещё нет. Запросы формируются в блоки и толкутся в оперативной памяти.

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

> чтобы не забивать кеш в обе стороны

Я как раз таки и хотел увеличить производительность за счет забивания кеша.

> iostat и спроси

Что именно у него спрашивать? Номинального значения wrqm/s для своего винта я не знаю.

> Т. е. это можно отключить.

Отключил. И lazy-counters включил, правда журнал во вторую версию конвертнуть не получилось.

> Ненадёжно (в случае поломки всё поломанное файло придётся перекачивать, это не восстановить), но быстро.

Для файлопомойки самое оно, на мой взгляд.

> BFQ

Он на разве не на low-latency ориентирован?

> С продакшеновыми ФС дома только морока лишняя.

Я когда-то давно с ext3 намучался сильно, с тех пор использую xfs по дефолту почти везде. Ext4 даже как-то пробовать не хочется, уж больно много недостатков она от 3й версии унаследовала.

>>91808

> Контроллер куда новее винта и не самый плохой.

Окей. Продолжим философствовать без единого выхлопа.

> А диски - я слышал что у современных дисков проблемы с временем произвольного доступа.

«слышал»? Где? Ничего там не меняется уже несколько лет. Плотность чуть-чуть повышают, упёрлись в плотность – увеличивают количество блинов. На времени слабо сказывается.

> Разница между старым десктопным веником и 'SAS 15,000RPM, 2 disks, RAID 1' довольно существенная.

Твоя претензия была к какому-то «времени отклика», которое в тех тестах нигде не фигурирует.

> При том, что каждый из потоков качает произвольный кусок произвольного файла и пишет его на винт. Торрент же.

У меня сейчас сидируются 56 торрентов, из которых активно – 12, по 20 пиров на торрент. При этом htop показывает два потока у главного процесса rtorrent. Из этого я делаю вывод, что потоки не соотносятся с кусками файлов. По крайней мере, в libtorrent. И вообще, если подумать, это выглядит, как дикость – на каждый кусок открывать новый сокет, пихать это всё в отдельный тред?..

> Я как раз таки и хотел увеличить производительность за счет забивания кеша.

Но производительности не будет, если контроллер, кеш и диск будут пытаться работать одновременно в обе стороны до самых мелких операций-запросов.

> Что именно у него спрашивать? Номинального значения wrqm/s для своего винта я не знаю.

Берёшь, кусаешь раздел, трёшь, копируешь в него какой-нибудь BD-образ, смотришь iostat в отдельном окне, нэ?

> Он на разве не на low-latency ориентирован?

Эт я по себе, забей. У меня диск всего один.

> с тех пор использую xfs по дефолту почти везде.

…и не могу даже отключить журнал. _Простите, не удержался._ Мне больше импонирует стабильность и восстанавливать экстейшен куда проще.

>>91811

> «слышал»? Где?

Новый винт:
http://www.reboot911.com/product/seagate-st31500541as-15tb-hard-drive-5900rpm-32mb-cache-sata-3g

> Random read seek time 16.0ms

Старый винт:
http://www.newegg.com/Product/Product.aspx?Item=N82E16822145137

> Average Seek Time 8.5ms

> При этом htop показывает два потока у главного процесса rtorrent. Из этого я делаю вывод, что потоки не соотносятся с кусками файлов. По крайней мере, в libtorrent.

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

> Но производительности не будет, если контроллер, кеш и диск будут пытаться работать одновременно в обе стороны до самых мелких операций-запросов.

Переключение между чтением и записью занимает существенное время? Я об этом ничего не слышал.

> Берёшь, кусаешь раздел, трёшь, копируешь в него какой-нибудь BD-образ, смотришь iostat в отдельном окне, нэ?

Это будет линейная запись, на ней винты ведут себя совсем по другому, поскольку не нужно дергать головкой 100 раз в секунду.

> Мне больше импонирует стабильность и восстанавливать экстейшен куда проще.

Это уже тема для отдельного срача пожалуй.

>>91808

> Отключил. И lazy-counters включил, правда журнал во вторую версию конвертнуть не получилось.

Похоже помогло, если верить iostat. А я похоже бака. Большую часть времени винт висит с нулевым w/s. Теперь осталось понять почему же все-таки тормозит rotrrent.

Спасибо.

>>91812
Ну ты сравнил, конечно. 7200 и 5900. Полтора терабайта и 500 ГБ, если там блинов одинаково, то плотность разнится пропорционально объёму. Сегодня можно купить купить и старые барракуды по терабайту (по 500 на пластину) с гарантией 5 лет.

> Переключение между чтением и записью занимает существенное время?

А хз, но пакетная передача всегда шустрее челночной.

> Это будет линейная запись, на ней винты ведут себя совсем по другому

То ты жалуешься, что тебе не с чем сравнивать, теперь в чём дело? Вот тебе будет и эталон.

> Теперь осталось понять почему же все-таки тормозит rotrrent

В чём это проявляется?

>>91820

> если там блинов одинаково, то плотность разнится пропорционально объёму.

Именно, вот и время доступа побольше.

> А хз, но пакетная передача всегда шустрее челночной.

Там все равно скорость далеко не в интерфейс упирается.

> То ты жалуешься, что тебе не с чем сравнивать, теперь в чём дело? Вот тебе будет и эталон.

Недостижимый в принципе причем. Я уже говорил, что линейная скорость винта у меня 30.

> В чём это проявляется?

Интерфейс лагает. Сейчас обновил, поставил буферы в 4 метра, вроде получше стало, надо будет под хорошей нагрузкой проверить.

>>91821

> Именно, вот и время доступа побольше.

Я думал ты про какие-то новомодные модели с кешами по 128Мб. Смысл разные размеры и обороты сравнивать вообще? Нормальные люди сравнивают при прочих равных. А то получается как у наших ВВС: «ПАК ФА незаметнее F-16».

> Там все равно скорость далеко не в интерфейс упирается.

Кстати, в своё время тестил пропускную всего от шины до оперы, шина-контроллер и диск-контроллер. Вроде нигде затыков быть не должно, а пропускная всё равно низкая. Реальный мир против даташитов.

> Я уже говорил, что линейная скорость винта

Для начала define «линейная скорость винта» в таком случае.

> Интерфейс лагает.

Если просто смотришь, он через 3-5 секунд сам обновляется? Лагать начинаешь, когда стопаешь-запускаешь?

>>91822

> Смысл разные размеры и обороты сравнивать вообще?

Чтобы понять, есть ли смысл менять старый винт на винт с новыми размерами и оборотами. У меня получается что сильно большоо смысла нету.

> Кстати, в своё время тестил пропускную всего от шины до оперы, шина-контроллер и диск-контроллер. Вроде нигде затыков быть не должно, а пропускная всё равно низкая. Реальный мир против даташитов.

Может что-то не учел? Например сам диск медленный.

> Для начала define «линейная скорость винта» в таком случае.

Запись/чтение без lseek()ов.

> Если просто смотришь, он через 3-5 секунд сам обновляется? Лагать начинаешь, когда стопаешь-запускаешь?

Затыки в 3-5 секунд, когда интерфейс не отзывается и данные не передаются. Начиналось когда скорость закачки вырастала выше 15 мегабайт в секунду.