On 01/20/14 14:55, Slawa Olhovchenkov wrote:
On Mon, Jan 20, 2014 at 02:51:06PM +0400, Anton Yuzhaninov wrote:
On 01/20/14 13:55, Slawa Olhovchenkov wrote:
не совсем. на таких мелких объемах начинают играть другие эффекты и в
результате с производительностью оказывается не так все хорошо, как
хотелось, а геморой с контентом уже есть.
А можно на этом месте подробней?
ну если делать по FS на диск, то закон больших чисел начинает плохо
работать и отдельные диски могут стать перегруженными обращениями
вдобавок контент начинает быть привязанным своими именами к физической
структуре. геморойчик!
В задаче раздачи контента с дисков всё обычно упирается в диски, а не другие
ресурсы сервера или сетевой интерфейс (мало гигабита - можно сделать два
гигабита в ether channel), так что дальше - про диски.
Если один большой массив распределяет данные по дискам, так что один файл лежит
на одном (паре) дисков, то все происходит так же как и с несколькими отдельными
FS - если на диске (паре дисков) лежит популярный файл, этот диск(и) будет
загружен сильнее других.
Если один большой файл раскидывается по N дискам, то все еще хуже.
У современных HDD достаточно большая пропускная способность, но при этом
относительно больше время seek time. Когда мы читаем большой кусок данных с
одного диска - seek происходит только на одном диске, а если он рассыпан по
N-дискам, то seek-и делают N-дисков. Общее число seek-ов в системе растёт, а
значит и в пересчёте на один диск тоже будет больше seek-ов.
Да, это N дисков будут загружены очень равномерно, но при этом в среднем они
будут загружены сильнее.
Распределение данных по N дисков может быть полезно в случае мелких файлов
(размер файла меньше размера stripe size или его аналога), но исходная задача
была про большие файлы.
Что же касается закона больших чисел, то он как раз работает за разбиение. На 4
Tb диск нормально поместится 350 - 3500 файлов. При достаточно случайном
распределении файлов по серверам/дискам, они скорее всего будут загружены
равномерно.
