amarao (amarao_san) wrote,
amarao
amarao_san

Category:

продолжая о теории иопсов

Интеловцы на конференции (IDF) озадачили меня ещё одним параметром, влияющим на совокупную производительность системы - это latency. В частности, они сказали крайне любопытную вещь в отношении SSD - снижение размера очереди уменьшает latency, т.к. чем выше размер очереди, тем больше в среднем в ней находится заданий и тем дольше каждое задание ждёт исполнения.

Соответственно, после решения проблемы общей производительности системы, становится задача обеспечения высокой производительности для каждого из обращающихся.

Ситуация обретает особую интригу в условиях очень массового (по моим прикидкам - порядка 300-600) параллелизма.

Производительность системы ДЛЯ КЛИЕНТА совсем не эквивалента общей производительности системы. Даже если эта система не загружена полностью.

Грубо говоря, имеем СХД, обеспечивающую потолок в 10000 иопсов, имеем нагрузку на СХД в объёме 3000 иопсов. (пока оставляем в стороне краевые эффекты throttling'а) для 1000 клиентов. Таким образом, мы имеем время обслуживания единичного иопса в 0.1мс.

Вопрос: какое число иопсов сможет для себя получить клиент? Наивный ответ - 7000. Но это неправда, потому что, если запросы от клиента сериализуются (а это так), то он будет становиться в очередь и ждать, пока обслужат всех остальных клиентов.

Допустим, глубина очереди 32. Т.к. запросы поступают в режиме белого шума (или, хотя бы, не строго один за одним), то в какой-то момент мы имеем почти заполненную очередь, то есть очередной запрос приходит как №31 в эту очередь. Таким образом, ему придётся ожидать исполнения 32*0.1=3.2мс. Заметим, что время худшего ожидания во внутренней очереди системы не зависит от загруженности системы, т.к. загруженность системы сказывается на задержках _ДО_ попадания в очередь, но не в очереди. В принципе, загруженность и характер нагрузки определяют как часто возникают такие cognession.

Но, вернёмся к худшей оценке. Если мы всё время будем попадать в самый конец очереди, то мы получим ... 312 ИОПС. Вместо наивных 7000. Разумеется, это оценка самая худшая.

Я, к сожалению, в этом месте развожу руками при попытке посчитать средний размер очереди (как это вообще посчитать? Вероятнее всего, есть соответствующая теория...), но я точно могу сказать, что худшая оценка индивидуальной производительности системы определяется именно тем, как долго запрос будет находиться в очереди, то есть её длинной.

Например, в примере выше, если мы _уменьшим_ очередь с 32 до 8, то худшая оценка возрастёт до 1250. Именно про уменьшение размера очереди интеловцы и говорили в вопросах тюнинга производительности SSD на IDF.

У меня остаются вопросы: как рассчитать не худшую, а "среднюю по больнице" загруженность очереди при известной (гипотетической) производительности и текущей загруженности? Какая теория это регулирует? В идеале хотелось бы видеть линк на готовые выводы, потому что на математику меня явно не хватит.
Tags: iops, storage, администрирование
Subscribe

  • фотографическое

    Ах, да, ещё. Рисование меня научило одной простой вещи в фотографии: если нет очень серьёзной причины камера должна быть строго горизонтальна. Не…

  • Вернулся с гор

    Оделся как положено, 4 слоя (майка, футболка, бейсболка "с начёсом", ветровка), штаны. Когда на улицу выходил, чувствовал себя идиотом (я на работу в…

  • HDR животворящий

    Дано: три фотографии с разницей в 0.3EV, какое-то забытое старьё в архиве непроявленного. Результат: баловство в luminance HDR (опенсорс).…

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 16 comments

  • фотографическое

    Ах, да, ещё. Рисование меня научило одной простой вещи в фотографии: если нет очень серьёзной причины камера должна быть строго горизонтальна. Не…

  • Вернулся с гор

    Оделся как положено, 4 слоя (майка, футболка, бейсболка "с начёсом", ветровка), штаны. Когда на улицу выходил, чувствовал себя идиотом (я на работу в…

  • HDR животворящий

    Дано: три фотографии с разницей в 0.3EV, какое-то забытое старьё в архиве непроявленного. Результат: баловство в luminance HDR (опенсорс).…