7.2K около строки SAS с большим кэшем RAID-контроллера по сравнению с 10/15K SAS
Учитывая большую часть файла сервисы загрузки используют общие и полезные протоколы, такие как HTTP/HTTPS по 80/443, вероятно, имеет больше смысла блокировать нежелательные домены через Ваш прокси, а не протоколом.
Я не уверен, что вы получите здесь полезный ответ. Я бы проводил тесты с приложением и предполагаемым оборудованием, чтобы получить представление о том, как оно работает, потому что я подозреваю, что существует достаточно сложность, поэтому попытка смоделировать ее «изнутри», вероятно, будет слишком упрощенной.
В целом Кэш на контроллере может буферизовать записи и позволяет тому RAID быстрее реагировать на операционную систему. Если ваша скорость записи превышает скорость, при которой кэш может быть зафиксирован на диске достаточно долго, чтобы заполнить кеш, тогда контроллер начнет блокировать записи (возвращаясь к скорости физических дисков).
Похоже, вы вы не используете стандартную систему управления базами данных, а, скорее, сами управляете хранилищем данных. Вы' Вам нужно будет оценить, как ваше приложение взаимодействует с диспетчером кеша ОС и базовой файловой системой (при условии, что вы не храните данные на необработанных дисковых блоках), а также с контроллером RAID. Если вы используете систему управления базами данных, тогда, очевидно, вам также придется увидеть, как она взаимодействует.
Когда вы говорите «работа над», мне интересно, участвовали ли вы в разработке приложения. Если это так, я думаю, что стоит взглянуть на архитектуру приложения, которая буферизует входящие записи в последовательно записываемый журнал, а затем выполняет отложенную запись этого последовательного журнала в структуру хранилища с произвольным доступом. По сути, вы выполняете то же самое, что пишет кэширование контроллера, но вы
Или, другими словами, компенсирует ли большой кэш на контроллере с точки зрения записи более медленное время поиска?
В определенной степени. Необходимо учитывать несколько факторов:
- кеш будет иметь желаемый эффект только до тех пор, пока он не будет переполнен - если ваши данные поступают пакетами или с постоянной скоростью, когда диски не могут справиться с нагрузкой, кеши будут заполнены вверх, в худшем случае это блок ввода-вывода до тех пор, пока кеши не будут сброшены до отметки низкого уровня для дальнейшей работы
- . Алгоритмы кэширования часто гарантируют, что данные в кэше могут быть не старше "X", инициируя сброс даже для них когда еще есть место для
- кэширования, выполняется «блоками», поэтому даже если размер ваших записей составляет всего 16 байт, это не означает, что вы можете хранить 67 миллионов записей в 1 ГБ кэш-памяти
- , смешанная нагрузка случайного чтения / записи трудна даже для большего кеша
- , вы вполне можете столкнуться с заполнением очередей команд даже с большими кешами, поэтому, если ваши требования к хранилищу включают не только IOPS и требования к полосе пропускания, но и низкую задержку (низкое время обслуживания), чего было бы трудно достичь с помощью данных параметров настройки
Некоторая математическая оценка: предполагая, что типичное время обслуживания для одного запроса будет За 20 мсек для SATA-дисков, подключенных к сети, подсистеме ввода-вывода потребуется 200 000 секунд, чтобы записать 10 000 000 на диски - это больше, чем 55 часов при 100% использовании диска . Если вы получаете такое количество запросов на запись в день, вы, вероятно, переполните свою подсистему ввода-вывода.
Насколько сильно вы столкнетесь с тем или другим граничным условием, сильно зависит от реализации контроллера и его механизма кэширования. Вам нужно будет провести тщательные тесты, чтобы не было неприятных сюрпризов.
Если кэш RAID является ограничивающим фактором (один из предыдущих ответов указывает на то, что это может быть), я бы подумал о добавлении некоторых интеллектуальных функций к кешированию впереди, чтобы чередовать записи по отдельным массивам - скажем, 4 зеркала по 2 диска в каждом - и хэширование места назначения для равномерного распределения нагрузки.
Это не улучшит использование кеша как таковое, но предоставит вам 4 набора независимых шпинделей для записи, что позволит избежать большей части задержка, связанная с необходимостью записи сразу на все шпиндели.
Однако, как сказал первый респондент, вам нужно проверить, что работает лучше всего.
Задумывались ли вы о H700 с кеш-памятью 512 или 1 ГБ, а затем вставляете один или два SSD для использования в качестве дополнительного кеша для дисков. Dell называет это своей технологией Cachecade.
См. Здесь: http://www.dell.com/downloads/global/products/pedge/en/perc-h700-cachecade.pdf