Jump to content
Korean Random
Sign in to follow this  
C.M.

Срок службы SSD. Износ на реальных примерах и влияние Redis и PostgreSQL

Recommended Posts

 

Статья от NikolaySivko из блога компании okmeter.io

 

 


 

om2tzsodob2fsf8r0qrsifs2_da.png

 

Год назад мы добавили в наш агент сбор метрик из S.M.A.R.T. атрибутов дисков на серверах клиентов. В тот момент мы не стали добавлять их в интерфейс и показывать клиентам. Дело в том, что метрики мы снимаем не через через smartctl, а дергаем ioctl прямо из кода, чтобы этот функционал работал без установки smartmontools на серверы клиентов.
Агент снимает не все доступные атрибуты, а только самые значимые на наш взгляд и наименее вендор-специфичные (иначе пришлось бы поддерживать базу дисков, аналогичную smartmontools).
Сейчас наконец дошли руки до того, чтобы проверить, что мы там наснимали. А начать было решено с атрибута "media wearout indicator", который показывает в процентах оставшийся ресурс записи SSD. Под катом несколько историй в картинках о том, как расходуется этот ресурс в реальной жизни на серверах.

Существуют ли убитые SSD?

Бытует мнение, что новые более производительные ssd выходят чаще, чем старые успевают убиться. Поэтому первым делом было интересно посмотреть на самый убитый с точки зрения ресурса записи диск. Минимальное значение по всем ssd всех клиентов — 1%.

 

Мы сразу же написали клиенту об этом, это оказался дедик в hetzner. Поддержка хостера сразу же заменила ssd:

 

zdffcfwxk-byiavhepxbi2wahh8.png

 

Очень интересно было бы посмотреть, как выглядит с точки зрения операционной системы ситуация, когда ssd перестает обслуживать запись (мы сейчас ищем возможность провести умышленное издевательство над ssd, чтобы посмотреть на метрики этого сценария:)

Как быстро убиваются SSD?

Так как сбор метрик мы начали год назад, а метрики мы не удаляем, есть возможность посмотреть на эту метрику во времени. К сожалению сервер с наибольшей скоростью расхода подключен к okmeter только 2 месяца назад.

 

iyn7c9otfrjy58f_jmwqkyz3ife.png

 

На этом графике мы видим, как за 2 месяца сожгли 8% ресурса записи. То есть при таком же профиле записи, этих ssd хватит на 100/(8/2) = 25 месяцев. Много это или мало не знаю, но давайте посмотрим, что за нагрузка там такая?


b2hn6xjbklijgcoqzpysn4vel54.png


Видим, что с диском работает только ceph, но мы же понимаем, что ceph это только прослойка. В данном случае у клиента ceph на нескольких нодах выступает хранилищем для кластера kubernetes, посмотрим, что внутри k8s генерирует больше всего записи на диск:

 

gm9en9hd8i7avo7th8_xvfnulte.png

 

Абсолютные значения не совпадают скорее всего из-за того, что ceph работает в кластере и запись от redis приумножается из-за репликации данных. Но профиль нагрузки позволяет уверенно говорить, что запись иницирует именно redis. Давайте смотреть, что там в редисе происходит:

 

rn5bieuh9ac3lb2kdizdwhu7wdi.png

 

тут видно, что в среднем выполняется меньше 100 запросов в секунду, которые могут изменять данные. Вспоминаем, что у redis есть 2 способа записывать данные на диск:

 

  • RDB — периодические снэпшоты всей баз на диск, при старте redis читаем последний дамп в память, а данные между дампами мы теряем
  • AOF — пишем лог всех изменений, при старте redis проигрывает этот лог и в памяти оказываются все данные, теряем только данные между fsync этого лога


Как все наверное уже догадались в данном случае используется RDB с периодичность дампа 1 минута:
 

fqughixpkwphosqk5xdzmrmcjqo.png

SSD + RAID

По нашим наблюдениям существуют три основных конфигурации дисковой подсистемы серверов с присутствием SSD:

  • в сервере 2 SSD собраные в raid-1 и там живет всё
  • в сервере есть HDD + raid-10 из ssd, обычно используется для классических РСУБД (система, WAL и часть данных на HDD, а на SSD самые горячие с точки зрения чтения данные)
  • в сервере есть отдельностоящие SSD (JBOD), обычно используется для nosql типа кассандры

 

В случае, если ssd собраны в raid-1, запись идет на оба диска, соответственно износ идет с одинаковой скоростью:

u-s9cebna9pesosskabhwzwzgwo.png

 

Но на глаза попался сервер, в котором картинка другая:

mkxng_b0bng33epewwav3ue7hew.png

 

При этом cмонтированы только партиции mdraid (все массивы raid-1):
pg9ggyky_kdfdo6jefefzpje1ew.png

 

По метрикам записи тоже видно, что на /dev/sda долетает больше записи:

1m2zjpefjue-rsneaasygdblkee.png

 

Оказалось, что одна из партиций на /dev/sda используется в качестве swap, а swap i/o на этом сервере достаточно заметно:

pc-bkvbw5tat57qw9frcvgxyfbq.png

Износ SSD и PostgreSQL

На самом деле я хотел посмотреть скорость износа ssd при различных нагрузках на запись в Postgres, но как правило на нагруженных базах ssd используются очень аккуратно и массивная запись идет на HDD. Пока искал подходящий кейс, наткнулся на один очень интересный сервер:

ptgaqs7cvz99zi16nt6jktvg8qw.png

 

Износ двух ssd в raid-1 за 3 месяца составил 4%, но судя по скорости записи WAL данный постгрес пишет меньше 100 Kb/s:

lbsjzhzao54qovnsgan0zqif508.png

 

Оказалось, что постгрес активно использует временные файлы, работа с которыми и создает постоянный поток записи на диск:

o0dytrgxlb3fq3fhyg-k013nuvw.png

 

Так как в postgresql с диагностикой достаточно неплохо, мы можем с точностью до запроса узнать, что именно нам нужно чинить:

okdl3khufsihxat-l--6mp7wijy.png

Как вы видите тут, это какой-то конкретный SELECT порождает кучу временных файлов. А вообще в постгресе SELECT'ы иногда порождают запись и без всяких временных файлов.

Итого

  • Количество записи на диск, которую создает Redis+RDB зависит не от количества модификаций в базе, а от размера базы + интервала дампов (и вообще, это наибольший уровень write amplification в известных мне хранилищах данных)
  • Активно используемый swap на ssd — плохо, но если вам нужно внести jitter в износ ssd (для надежности raid-1), то может сойти за вариант:)
  • Помимо WAL и datafiles базы данных могут ещё писать на диск всякие временные данные

Share this post


Link to post

Short link
Share on other sites

Какая память самая износостойкая оказалась и какого производителя? SSD какой фирмы имеет наименьшее количество отказов?  

Share this post


Link to post

Short link
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...