Comments 16
Хороший материал, но не хватает примеров и наглядности.
(Еще не поздно добавить)
(Еще не поздно добавить)
Поддерживаю. Может немного примерчиков для разных ОС с графиками было бы идеально
добавил пример
Тут больше зависимости от дисковой подсистемы, чем от операционки. VxFS на разных операционках примерно одинаковый. Различия могут быть вызваны архитектурой файлового кеша, где хранятся данные read ahead и ограничениями стека ввода-вывода (например на количество параллельных IO).
Больше всего конечно влияет дисковая подсистема и пропускная способность SAN.
ps. smartdrv.exe, вроде как, просто кеш был. равно как и ptscache.sys
Больше всего конечно влияет дисковая подсистема и пропускная способность SAN.
ps. smartdrv.exe, вроде как, просто кеш был. равно как и ptscache.sys
Сущесвет ли подобное для более «часых» файловых систем (XFS, ext3/4)?
У меня другой вопрос — существует ли в современном мире файловая система, где этого нет.
я просто с ними не работаю, поэтому не знаю. Однажды возился с ext4 но недостаточно, чтобы рассказать.
Насколько я понимаю, это функция ядра, а не [драйвера] файловой системы. В линуксе смотреть и управлять кешем можно с помощью команды blockdev. Пример с VxFS — это какой-то частный случай.
А что же Вы не привели реальных цифр с разницей до\после?
Интересно ещё увидеть зависимость от типа массивов. Примерно на практике мы с ней сталкиваемся, но коэффициенты и зависимости красивей смотрятся на графиках. И ещё на блюдечке с голубой каёмочкой. :-)
Мда… Статья недоделана. Где конкретные команды для vxtunefs? Где хоть какое-то сравнение производительности до и после оптимизации? Где хоть какой-то пример из жизни?
Фразы вроде «Иначе, последствия могут быть непредсказуемыми» сразу говорят о том, что вы ниразу не пробовали отойти от мануалов. Очень похоже, что это просто краткая выдержка из официального гайда по тюнингу VxFS.
По поводу использования SAN — скорость скорее всего в него и упрется. Когда на предыдущем месте работы мы настраивали бекапы на ленточки и на евы — приходилось мучатся с мультипасингом — руками сносить лишние пути, тк они только мешали.
Фразы вроде «Иначе, последствия могут быть непредсказуемыми» сразу говорят о том, что вы ниразу не пробовали отойти от мануалов. Очень похоже, что это просто краткая выдержка из официального гайда по тюнингу VxFS.
По поводу использования SAN — скорость скорее всего в него и упрется. Когда на предыдущем месте работы мы настраивали бекапы на ленточки и на евы — приходилось мучатся с мультипасингом — руками сносить лишние пути, тк они только мешали.
Вы правы, я не люблю отходить от мануалов. По мне, буквальное следование мануалам — главный секрет успеха в этой профессии. По поводу непредсказуемых последствий, да, вплоть до kernel panic. Поэтом и пишу. Обычно, паники очень непредсказуемы. Кроме того, если буфера в файловом кеше имеют размер страницы памяти (например 4kb), логично читать блоком с кратным 4kb?
Основная проблема многих бэкапов — однопоточность. Если распараллелить на уровне приклада нельзя, то read ahead один из возможных путей. Он позволяет нескольким IO отправляться в массив почти параллельно. Понятно что может упираться в SAN, порт на массиве, число шпинделей, scsi queue, итд.
Основная проблема многих бэкапов — однопоточность. Если распараллелить на уровне приклада нельзя, то read ahead один из возможных путей. Он позволяет нескольким IO отправляться в массив почти параллельно. Понятно что может упираться в SAN, порт на массиве, число шпинделей, scsi queue, итд.
Sign up to leave a comment.
Оптимизация скорости бэкапов средствами файловой системы (read ahead, опережающее чтение)