История изменений

Я выше объяснил в чём будет разница. У тебя либо 100 потоков на рейд, которые превращаются в 100 потоков на каждый диск, либо 100 потоков на 8 независимых дисков, которые распределяются по 10-15 на диск.

Тут может крыться косячок. Мозаичка гарантированно размазывает каждый мегабайт по всем 8 дискам и 100 потоков на каждый диск запросят не по 1М а по 128К и в 8 раз быстрее освободят их. А вот ты рискуешь что все 100М (а не по 12,5М) упадут на один единственный диск.

И риск тут вот нихрена не нулевой. У меня торренты раньше по 3 дискам вручную раскидывались, так вот при раздаче ~400 штук в теории нагрузка должна была отбалансироваться, а на практике была чудовищно рваной и почти всегда сваливалась на 1 конкретный. Почему ты думаешь, что с высоконагруженным веб-сервером не произойдёт того же из за какого нибудь ЛОР-эффекта. Ну да, ты балансировал-балансировал, но вот именно в этот вечер вот эта тема хайпанула, а её файлы лежат на диске 3 и только на диске 3. Бежим и срочно перетасоваем на лету?

Блок 32к, 2 блока 64к? Хорошо, на одном диске у тебя уйдёт в среднем 10мс на позиционирование + ожидание нужного поворота диска и 0.6мс на собственно чтение. На рейде из двух у тебя уйдут всё те же 10мс на позиционирование + ожидание нужного поворота и 0.3мс на чтение по 32кб с каждого. 10.3 против 10.6 - выиграл целых 3% времени, ценой того что занял оба диска работой вместо одного. Эффективная скорость в расчёте на один диск упала почти в 2 раза.

Не, ты же так хочешь многопоток! А значит если операция потребует 2 блока, то между ними шедулеру накидают длинную очередь из других потоков и на одном диске ты получишь 10мс на позиционирование + 0,3мс на чтение + 10мс на позиционирование + 0,3мс на чтение. И ещё плюсом ожидание других таких же хаотичных запросов в очереди. И мозаичка здесь отработает идентично твоему разбросу. Её преимущество, как я писал выше - в простом и эффективном балансировании нагрузки сразу на все диски.

Здесь вообще надо смотреть на дисковые кеши, алгоритм его врутренего использования, твикинг шедулера, в идеале агресивная и сверхдлинная очередь чтобы соборать кучу запросов со всех 100 потоков и потасовать их какое то время пока не прорисуется оптимальный маршрут головок. Или сверхагресивное кеширование, типа запрос был на 3*4К блока, но мы читаем оптом всю дорожку/сектор на ~10М и пусть пока полежит в кеше, вдруг запрос всё таки придёт.

А если всё таки потоков мало, а файлы крупные - преимущество мозаички очевидное. Этот способ позволяет прочитать файл быстрее чем с 1 единственного диска. А если файлы мелкие, то они что так, что так попадают на 1 диск. Тут просто надо грамотно выбрать оптимальный размер блока чередования.

Я выше объяснил в чём будет разница. У тебя либо 100 потоков на рейд, которые превращаются в 100 потоков на каждый диск, либо 100 потоков на 8 независимых дисков, которые распределяются по 10-15 на диск.

Тут может крыться косячок. Мозаичка гарантированно размазывает каждый мегабайт по всем 8 дискам и 100 потоков на каждый диск запросят не по 1М а по 128К и в 8 раз быстрее освободят их. А вот ты рискуешь что все 800М упадут на один единственный диск.

И риск тут вот нихрена не нулевой. У меня торренты раньше по 3 дискам вручную раскидывались, так вот при раздаче ~400 штук в теории нагрузка должна была отбалансироваться, а на практике была чудовищно рваной и почти всегда сваливалась на 1 конкретный. Почему ты думаешь, что с высоконагруженным веб-сервером не произойдёт того же из за какого нибудь ЛОР-эффекта. Ну да, ты балансировал-балансировал, но вот именно в этот вечер вот эта тема хайпанула, а её файлы лежат на диске 3 и только на диске 3. Бежим и срочно перетасоваем на лету?

Блок 32к, 2 блока 64к? Хорошо, на одном диске у тебя уйдёт в среднем 10мс на позиционирование + ожидание нужного поворота диска и 0.6мс на собственно чтение. На рейде из двух у тебя уйдут всё те же 10мс на позиционирование + ожидание нужного поворота и 0.3мс на чтение по 32кб с каждого. 10.3 против 10.6 - выиграл целых 3% времени, ценой того что занял оба диска работой вместо одного. Эффективная скорость в расчёте на один диск упала почти в 2 раза.

Не, ты же так хочешь многопоток! А значит если операция потребует 2 блока, то между ними шедулеру накидают длинную очередь из других потоков и на одном диске ты получишь 10мс на позиционирование + 0,3мс на чтение + 10мс на позиционирование + 0,3мс на чтение. И ещё плюсом ожидание других таких же хаотичных запросов в очереди. И мозаичка здесь отработает идентично твоему разбросу. Её преимущество, как я писал выше - в простом и эффективном балансировании нагрузки сразу на все диски.

Здесь вообще надо смотреть на дисковые кеши, алгоритм его врутренего использования, твикинг шедулера, в идеале агресивная и сверхдлинная очередь чтобы соборать кучу запросов со всех 100 потоков и потасовать их какое то время пока не прорисуется оптимальный маршрут головок. Или сверхагресивное кеширование, типа запрос был на 3*4К блока, но мы читаем оптом всю дорожку/сектор на ~10М и пусть пока полежит в кеше, вдруг запрос всё таки придёт.

А если всё таки потоков мало, а файлы крупные - преимущество мозаички очевидное. Этот способ позволяет прочитать файл быстрее чем с 1 единственного диска. А если файлы мелкие, то они что так, что так попадают на 1 диск. Тут просто надо грамотно выбрать оптимальный размер блока чередования.