Comments 15
Как видим, производительность записи на диск упала. Данный график стабильно воспроизводился при различных размерах считываемых данных. Объяснений этому у нас нет. Будем рады, если кто-то объяснит причины падения скорости.
Странно, меня одного это не удивило, наверно начитался всяких обзоров
На самом деле причин много:
Кто-то пишет:
Падение скорости работы заполненного под завязку SSD-диска связано с особенностью работы ячеек памяти. Каждый блок информации равен 512 килобайтам, а размещаться там может, к примеру, всего одна страница размером 4 килобайта. Но при этом весь блок информации будет считаться занятым. В отличие от HDD, в котором новые данные можно добавить к уже существующим или записать поверх старых, в SSD данные сначала считываются, а затем записываются по новой. Это приводит к замедлению скорости работы. Чтобы поддерживать скорость работы SSD-диска, с него надо регулярно «удалять мусор», и для этого существует функция TRIM.
Еще это могут объяснять логикой работы контроллера
> Еще это могут объяснять логикой работы контроллера.
Понятно, что просадка в производительности зависит от логики контроллера. Непонятно от каких алгоритмов произошла характерная периодичная просадка, зависящая от адреса блока.
Падение скорости при заполнении диска действительно существует и начинается примерно при использовании 80-90% от емкости диска. В данном тесте 42гб ушло на данные и 21гб на индекс, итого было занято 63гб из доступных 440гб.
Понятно, что просадка в производительности зависит от логики контроллера. Непонятно от каких алгоритмов произошла характерная периодичная просадка, зависящая от адреса блока.
Падение скорости при заполнении диска действительно существует и начинается примерно при использовании 80-90% от емкости диска. В данном тесте 42гб ушло на данные и 21гб на индекс, итого было занято 63гб из доступных 440гб.
Условия теста совершенно не описаны. Какие значения writeback/readahead на устройствах? Какая глубина очереди? Какой линуксовый менеджер очереди — noop, deadline, cfq? На каком из дисков хранится bitmap рейда (обновление которого отдельный набор операций, влияющий на производительность). Какой контроллер? Где синтетические тесты устройства в отсутствие БД для идентификации узких мест? Где информация об утилизации дисков и CPU во время нагрузочного тестирования?
Вижу шаманство «и потыкались чуть-чуть».
Вы хотя бы проверили, что рейд в параллель не занимался consistency checking?
Вижу шаманство «и потыкались чуть-чуть».
Вы хотя бы проверили, что рейд в параллель не занимался consistency checking?
Это первая часть статьи, тестирование на рейд массиве будет в следующей статье. Менеджер I/O — deadline. Загрузка процессора во время тестов составляла 30-50% с учетом того, что клиент запускался на этой же машине. За время указанного в статье теста процессор не становился узким местом.
А что становилось узким местом? Вы даже близко не показали чем вы мониторили утилизацию во время теста. С учётом что у вас все графики со странным графическим менеджером, то у меня даже возникает вопрос: а вы на происходящее на хосте вообще смотрели-то?
Ну там хотя бы что-то примитивное, вида atop'а, не говоря уже про более точные замеры io flight time.
Какая нагрузка доходила до SSD? Сколько IOPS, какая средняя глубина очереди, какой размер блока? Хотя бы сравнение поведения СУБД на одной SSD против двух.
То есть «посмотреть для себя» как оно работает — да, отлично, можно эти цифры использовать для прикидки конфигурации.
Для презентации результатов на публику — слишком много «я запустил крайсис и он не тормозит, значит моё водное охлаждение офигенное»
Ну там хотя бы что-то примитивное, вида atop'а, не говоря уже про более точные замеры io flight time.
Какая нагрузка доходила до SSD? Сколько IOPS, какая средняя глубина очереди, какой размер блока? Хотя бы сравнение поведения СУБД на одной SSD против двух.
То есть «посмотреть для себя» как оно работает — да, отлично, можно эти цифры использовать для прикидки конфигурации.
Для презентации результатов на публику — слишком много «я запустил крайсис и он не тормозит, значит моё водное охлаждение офигенное»
Утилизация дисков мониторилась через iostat. В дальнейшем учтем замечание и будем давать более подробное описание инструментов с помощью которых производился мониторинг.
iops на диск был в районе 10-20к. Размер блока стандартный — 512k.
Сравнение производительности на одном SSD и RAID будет в ближайшее время следующей статье.
iops на диск был в районе 10-20к. Размер блока стандартный — 512k.
Сравнение производительности на одном SSD и RAID будет в ближайшее время следующей статье.
Как вы сумели узнать «стандартный размер блока», да ещё так ровно кратно 512? Вы не путаете с размером страйпа рейда?
Действительно имел в виду размер страйпа. Размер взят из /proc/mdstat
А я говорил про средний размер блока, который писался на диск во время теста.
PostgreSQL был инициализирован с размером блока по умолчанию — 8кб. Согласно другим тестам postgres на SSD при изменении размера блока производительность не сильно изменяется, поэтому в завивимости от этого параметра тестирование не производилось.
Но блок postgres не определяет средний размер блока IO (если только вы noop в дисковом скедулере не включили). BIO могут объединяться для уменьшения числа операций.
При тестировании основной задачей было измерение производительности базы данных, определение узких мест, влияние настроек постгриса, сравнение различных конфигураций железа SSD/RAID-0 SSD/HDD.
Измерение «размера блока, который писался на диск» не было целью тестирования. Будем благодарны, если подскажите способы переконфигурирования системы для повышения производительности.
Измерение «размера блока, который писался на диск» не было целью тестирования. Будем благодарны, если подскажите способы переконфигурирования системы для повышения производительности.
Чтобы повысить производительность надо найти то, во что упирается система. Вы же не смотрели на утилизацию системы во время тестов. Из очевидного — попробовать поиграть с размером readahead'а, разными типами дисковых скедулеров (может быть noop будет быстрее), попробовать вынести метаданные рейда с массива.
Но ключевое — нужно найти «чего не хватает» чтобы получить более высокую производительность.
Но ключевое — нужно найти «чего не хватает» чтобы получить более высокую производительность.
А разве в ОС или в PostgreSQL нет кеширования файловых операций? Как вы выяснили, что всё именно в диск упирается? Какая была загрузка процессора? А пропускная способность оперативки не может быть узким местом?
Не в смысле, что я дико сомневаюсь. Я просто не понимаю, из чего это следует. Я вижу, что операции упираются в потолок, но из чего это следует?
Не в смысле, что я дико сомневаюсь. Я просто не понимаю, из чего это следует. Я вижу, что операции упираются в потолок, но из чего это следует?
И ОС и PostgreSQL имеют кеширование, просто размер базы и характер нагрузки таковы, что для большей части запросов требуемого блока не оказывается в кеше и его нужно считать с диска.
В данном тесте диск точно является узким местом — утилизация по iostat составляла 95-100%. Загрузка процессора с учетом клиента составляла 30-50%.
В данном тесте диск точно является узким местом — утилизация по iostat составляла 95-100%. Загрузка процессора с учетом клиента составляла 30-50%.
Sign up to leave a comment.
Тестируем PostgreSQL на SSD RAID-0 массиве с таблицей в 10 миллиардов записей. (Часть 1)