Я бы на месте разработчиков также не отвечал. Информации ноль. Почему не показано что конкретно в файловом кэше? Почему нету вывода всех параметров sysctl?
С такими исходными данными можно ежедневно по сто багов создавать.
если для Innodb выставить тип коммита O_DIRECT вместо стандартного sync/fdatasync, то на OpenVZ это приведет к очень крутому ускорению работы базы данных.
Ждать можно долго… В Debian уже есть. Для CentOS вот так:
sed -i 's/^mirrorlist=/#mirrorlist=/' /etc/yum.repos.d/CentOS-Base.repo
sed -i 's/^#baseurl=/baseurl=/' /etc/yum.repos.d/CentOS-Base.repo
yum clean all
yum makecache fast
yum update glibc
sed -i 's/^#mirrorlist=/mirrorlist=/' /etc/yum.repos.d/CentOS-Base.repo
sed -i 's/^baseurl=/#baseurl=/' /etc/yum.repos.d/CentOS-Base.repo
yum clean all
yum makecache fast
Какой смысл жевать историю годовой давности без каких либо дополнительных данных?
Читал статью в надежде увидеть ситуацию с другой стороны, а в результате понял что зря потратил свое время. Все это вы уже излагали неоднократно.
Лично мне, как человеку не знакомому с Канадой, было бы интересно почерпнуть такую информацию как выдержки из законодательства страны, из которых следует на каких основаниях можно изымать оборудование. Вы же подавали в суд, значит это все у вас под рукой, лень скопировать?
А пока статья смотрится так — через год вы, Максим, вспомнили что полиция выполнила свою работу не так как вам это хотелось.
Очень благодарю за столь развернутый ответ. Все советы приму в сведению в будущем.
Начал заниматься этим из-за того что не редко наблюдал, как множественные benchmark'и существенно отличаются от результатов на практике. В итоге прогнозируешь одно, получаешь совсем другое. В плане сравнения SATA/SAS еще можно делать кое-какие прогнозы, а вот сравнивать с SSD тяжело.
в одних графиках лучше — больше, в других лучше — меньше
Ну переворачивать ось Y верх ногами тоже неверно, согласитесь.
Чтобы сделать более корректные выводы нужен «зоопарк», как вы выразились, раз в 10 хотя бы больше. Ведь у каждой конкретной модели накопителя свои особенности.
Я бы сказал так, — поверхностный тест в целом и довольно определенный по конкретным моделям, массивам. Хотелось бы сделать больше, но возможности ограничены. Надеюсь и эти данные будут полезны сообществу.
Смысл статьи не определить кто быстрее: SAS, SATA, SSD. А определить как ведет себя тот или иной носитель себя в рейд-массивах и без них, как зависит скорость чтения/записи от количества дисков в массиве, а также разница между hardware raid и software raid.
В файл abcd.txt пишу 12345, после в файл abcd2.txt пишу 32568. Что здесь кэшировать? В реалиях данные сохраняются также.
Этим и плох ssd. Для физических hdd все рассчитывается просто.
Полностью поддерживаю. Но если использовать данные от fio, но ничего сравнить вовсе нереально. По этому не использовал.
Какой толк, если диски не были заполнены полностью?
habrahabr.ru/post/168711/#comment_5846147
Заполнение более 60% это не так мало. В реальности редко кто допускает большее заполнение, делается запас. Все тесты выполнялись без таймаута, за один подход. Т.е. нагрузка была разной, но была в течении всех тестов. «Отдохнуть» не было когда. Полностью все тесты занимали около 3-х часов.
С такими исходными данными можно ежедневно по сто багов создавать.
Это касается не только OpenVZ.
Читал статью в надежде увидеть ситуацию с другой стороны, а в результате понял что зря потратил свое время. Все это вы уже излагали неоднократно.
Лично мне, как человеку не знакомому с Канадой, было бы интересно почерпнуть такую информацию как выдержки из законодательства страны, из которых следует на каких основаниях можно изымать оборудование. Вы же подавали в суд, значит это все у вас под рукой, лень скопировать?
А пока статья смотрится так — через год вы, Максим, вспомнили что полиция выполнила свою работу не так как вам это хотелось.
Ничего личного, но статья ни о чем.
Начал заниматься этим из-за того что не редко наблюдал, как множественные benchmark'и существенно отличаются от результатов на практике. В итоге прогнозируешь одно, получаешь совсем другое. В плане сравнения SATA/SAS еще можно делать кое-какие прогнозы, а вот сравнивать с SSD тяжело.
Еще раз спасибо!
Ну переворачивать ось Y верх ногами тоже неверно, согласитесь.
Чтобы сделать более корректные выводы нужен «зоопарк», как вы выразились, раз в 10 хотя бы больше. Ведь у каждой конкретной модели накопителя свои особенности.
Я бы сказал так, — поверхностный тест в целом и довольно определенный по конкретным моделям, массивам. Хотелось бы сделать больше, но возможности ограничены. Надеюсь и эти данные будут полезны сообществу.
Смотрите тут и тут
В файл abcd.txt пишу 12345, после в файл abcd2.txt пишу 32568. Что здесь кэшировать? В реалиях данные сохраняются также.
Полностью поддерживаю. Но если использовать данные от fio, но ничего сравнить вовсе нереально. По этому не использовал.
Заполнение более 60% это не так мало. В реальности редко кто допускает большее заполнение, делается запас. Все тесты выполнялись без таймаута, за один подход. Т.е. нагрузка была разной, но была в течении всех тестов. «Отдохнуть» не было когда. Полностью все тесты занимали около 3-х часов.