Comments 69
с параметром iowait (процент простоя CPU в ожидании дисковых операций ввода/вывода)
Туда же относится ожидание ответа от сетевой подсистемы ввода-вывода.
А в целом за статью +, поделились полезным опытом.
> Совсем скоро после публикации той статьи в нашей компании появился Kingston SNE125-S2/64GB на базе SSD Intel x25m

Вы ничего не путаете? SNE сделан на базе x25e.
А какие у вас smart параметры после года использования?
Вот эти:
Код E1 – Host Writes
Код E9 – Media Wearout Indicator
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  3 Spin_Up_Time            0x0000   100   000   000    Old_age   Offline      -       0
  4 Start_Stop_Count        0x0000   100   000   000    Old_age   Offline      -       0
  5 Reallocated_Sector_Ct   0x0002   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0002   100   100   000    Old_age   Always       -       4732
 12 Power_Cycle_Count       0x0002   100   100   000    Old_age   Always       -       73
192 Unsafe_Shutdown_Count   0x0002   100   100   000    Old_age   Always       -       55
232 Available_Reservd_Space 0x0003   100   100   010    Pre-fail  Always       -       0
233 Media_Wearout_Indicator 0x0002   099   099   000    Old_age   Always       -       0
225 Host_Writes_32MiB       0x0000   200   200   000    Old_age   Offline      -       21659
226 Intel_Internal          0x0002   255   000   000    Old_age   Always       -       0
227 Intel_Internal          0x0002   000   000   000    Old_age   Always       -       0
228 Intel_Internal          0x0002   000   000   000    Old_age   Always       -       0

SMART Error Log Version: 1
No Errors Logged

Не сочтите за занудство, но тут: «В Linux проблемы со скоростью дисковой системой напрямую связаны» видимо «системы». А в целом за статью спасибо. Добавил в закладки. 8)
UFO landed and left these words here
может конечно скажу глупость — но вы не думаете, что придётся очень часто менять такие ssd диски — ведь у них число циклов чтение-запись весьма небольшое. А использовать их в качестве кеша, к которому как раз и пойдёт основной поток запросов на чтение мягко говоря глупо.

Спасибо за внимание.
да но ведь не написано сколько за это время убилось ssd… или я невнимательно читал?
Цитата:
I once ran a multi week attempt to burn out various vendors’ SSDs. I ran them flat out 100% random writes for about a month. Fusion IOs at something like 30k IOPs per drive, STECs / Intels around 7k. Never was able to get any of them to fail.
The Fusion IO did as many writes that month as a single SAS drive could do in over a decade.

PS. «decade» это «десять лет» в английском.
Да у него всего 600 гб записей за год. А лимит когда стоит начинать думать о износе в районе 50 тб.
Для преимущественно _отдачи_ конечное число циклов _записи_ не критично.
ограничено кол-во записей. а чтение — не ограничено вообще. даже когда ссд уже совсем не пишется — он будет читаться. пока там что-то не сгорит ))
Лично у меня iowait иногда доходит до 70%
точнее доходил.
Как ПРАВИЛЬНО победить задержки раздачи файлов для обычного сайта.
решение номер 1 —
Когда у вас спросят — сколько памяти ставить в новый сервер 2 или 4 гига — скажите «ставьте 16»
Лично у меня вся статика занимает ну максимум гигов 6. И я уверен — она всегда будет браться из кеша.

решение номер 2 —
NCQ, AIO и другие механизмы которые позволяют отдать больше файлов большему количеству клиентов с большими задержками.
Да именно что с большими — если системе надо будет подождать пару секунд чтобы жесткий более непрерывно выполнил свою работу — это позволит обработать СИЛЬНО большее количество клиентов ценой появления маленьких задержек. Ну и чем меньше клиентов тем меньше задержек

если же у вас файлопомойка и у вас много много файлов — вас окончательно не спасет никакое решение. Потому что решение которое вас спасет — себя просто не окупит

ПС: да, я абсолютно уверен что массив из обычных дисков + куча рама более эффективен чем ssd за те же деньги.
В статье написано, что размер кеша — 200G. Это примерно $1000 как ssd и раз в 10 дороже в виде ram.
Окей, вопрос номер два — что такое cache-hit, cache-miss и мифический «плоский»(равномерно-рандомный) вариант доступа к данным. Когда запрашиваются вроде как все, но вроде как один-два раза в день.
Так что путаем размер кеша и размер активно используемого кеша.

Когда я работал в викимапии система рендера тайлов сильно упиралась именно в «плоский» вариант доступа к данным. Иногда было быстрее не брать данные из кеша, а сгенерить их на месте чем просто поискать их в кеше и вернуть.
Но там кем был не 200G и даже не 2000G.
Мой 1 сервер раздачи отдает в среднем 100 000 — 150 000 фоток в минуту в штатном режиме и приблизительно 200 000 фоток в минуту (в пиковые часы). В вашем случае мы переносим нагрузку из кеша на процессоры. Для меня процессорное время дороже чес SSD кеш.
Вы наверное не обратили внимание, что первое что я бы апгрейдил — это имеено RAM, но не во всякую материнку можно поставить более 16G кеша. Кроме того если у Вас все фотки помещаются в 6G и Ваш сайт растет то это означает что когда нибудь Ваши 16G тоже Вас не спасут :)
При включенном механизме copy-on-write появляются дополнительные издержки в виде дискового пространства на SSD (На диск 64G при включенном copy-on-write и записи большого количество фоток размером 1-5K, влезало на ~8G меньше чем с nodatacow).
Справедливости ради надо сказать что я отключил не только copy-on-write пареметры nodatasum,noacl,notreelog тоже повлияли на вместительность SSD винта
Вот мы и подошли к самой интересной возможности btrfs: это создавать софтовые RAID-масыви и указывать явным образом, на каких дисках сохранять данные на каких метаданные
Что произойдет при «вылетании» диска с метаданными? Данные будут доступны при обычном монтировании диска?
На диске с метаданными хранится 2 копии метаданных. Если будут повреждены сразу две копии одновременно (что маловероятно для SSD) то надо запускать чекер и быть готовым к тому что часть кеша может не ввостановиться.
Пришла подсказка из зала, цитирую:
"
я сам писал статьи на эти темы еще лет 5-7 назад на computing.net когда все это начиналось! Но есть подводные камни которые отсутствуют в этой статье! SSD пока что не годится для высоконагруженных проектов!
Есть намного лучшее решение (которое было на рыеке с 2001года, а сейчас ушло далеко вперед! Я сам собирал серваки с Itanium 2 на основе этих накопителей!) ACARD ANS-9010 5.25" SATAx2 to DDR2 Ram Disk Drive
"
Для тех кому лень лезть по ссылке:
ACARD RAM Disk Box acts like a regular SATA hard drive at 400MB/s data transfer rate. By utilizing conventional DDR2 memory modules, ACARD ANS-9010 is outfitted with 8 240-pin DDR2 DIMM module slots and support up to 64GB memory. Most of all, the major issue of data lost after powering down is solved by RAM Disk’s backup battery plus CF slot for data backup.

Memory Interface
Memory Capacity: 64GB
Memory Slot: 8 240-pin DDR2 DIMM module slots
Memory Type: ECC/Non-ECC DDR2 400/533/667/800**

Цена правда: $327.00
> SSD пока что не годится для высоконагруженных проектов!

Реальность не подтверждает. SSD применяется очень широко уже сейчас, и темпы роста очень высокие.
Про уровень подсказки из зала становится понятно уже по одному только наличию восклицательного знака в конце каждого предложения. ;)
«Сейчас уже доступны диски, использующие технология SLC (Single-Level Cell) с «умным» конроллером.»

Вообщето изначально были доступны только SLC диски, MLC появились позже.

кроме того 100000 циклов перезаписи котороые приписываются SLC ячейкам сильно завышены.
Ваши сведения устарели. В области SSD все меняется к лучшему очень быстро. Сегодня ситуация с количеством циклов у современных SLC SSD в реальной жизни практически равна такой у HDD.

blog.aboutnetapp.ru/archives/669
вы путаете рекламируемое время жизни (MTBF) ssd по сравнению с hdd с количеством перезаписи одной ячейки. Интел например в последнем интеловском написано «1 петабайт рандомной записи за время жизни винта» для 32Г модели. если у вас полвинта занято и остальное перезаписывается регулярно это будет уже только 512 терабайт за время жизни и тд. При неслучайной записи до петабайта будет ой как далеко.

но даже петабайт при скорости 170 мегабайт в сек запишутся за 73 дня, что гораздо меньше 2 миллионов часов MTFB
Вы правда считаете, что я не различаю разницу между «MTBF» и реальным положением дел? ;)

Цитаты по ссылке, приведенной выше, это мнения админов-практиков, эксплуатирующих системы с деcятками и сотнями SSD.
все зависит от типа нагрузок, у меня например четыре интеловских SSD купленых для кеша полгода назад (нужна быстрая запись и паралельное чтение) уже показывают по паре десятков реаллоков, причем реально за эти полгода винты работали месяца три. Соответственно если мы пустим их из тестовой нагрузки в полную выйдут из строя за год (при этом они конечно себя окупят, но надо расчитывать время на даунтайм что тоже расходы)

С другой стороны у нас есть 4 15K SAS винта с чуть меньшей (процентов на 15) загрузкой на запись, но им уже по три года и до сих пор ни одного реаллока.

Даже 15к SASы не показывают такого времени доступа как SLC SSD.
В этом их прелесть.

Пока SAS только seek-ает SSD уже отдал данные.
привет кэп :)

P.S. в некоторых диапазонах размеров блоков на запись эти SAS таки немного быстрее, но только в очень узком диапазоне
«SLC с «умным» конроллером» от Intel появились в 2008 году. Нащет 100000 циклов не проверял, возможно єто маркетинговый ход.
Когда картинок очень много столкнулись с большим увеличением iowait с некоторой периодичностью. Как оказалось, следует отключить updatedb.
Я про это совсем забыл. Действительно, можно либо отрубить updatedb либо /etc/updatedb.conf прописать исключение для директории с кешом.
Коротко говоря — индексатор файлов.
При ~3 млн. картинок расположенных в структуре каталогов 256х256 iowait был около 50-60%.
А как вы смотрите на размещение СУБД на SSD?
По моим наблюдениям она у нас даёт основную нагрузку на io
Для базы данных я бы все же использовал RAID-массив из SAS-дисков. База данных породит намного больше трафика на запись.
Почему-то мне кажется, что современные SSD типа OCZ Vertex 2 очень умные и «размазывают» циклы записи по всем ячейкам памяти. Т.е. мереть как мухи под записью не должны.

И именно для СУБД применний SSD-диск кажется мне наиболее привлекательным
Мой знакомый собрал в RAID 4 обычных MLC SSD в аппаратный RAID на хостинговый сервак с LAMP системой. Они продержались 4 месяца и умерли практически одновременно. Это было год назад, возможно современные Vertex-ы продержались бы больше.
Для базы данных одним из самых ускоряющих факторов является кеш RAID-контроллера на запись.
У некотрых контроллеров Areca есть возможность в контроллер установить 4Gb кеш, вот это действительно дает уменьшене iowait.
Вывод из этого я могу сделать только один — нужно экспериментировать :)
И не забывать про регулярные бекапы, конечно.
Тут вот еще про что не стоит забывать. Для _хранения_ SSD вообще, в принципе, не очень экономически эффективен.
Какая часть вашей базы активно считывается и записывается в течение дня? 10%? 30%? Вряд ли сильно больше. Значит от 90 до 70% данных базы просто лежат занимая сверхдорогое пространство SSD, как они могли бы замечательно лежать на SATA за 80$, и от того, что они находятся на SSD, общая работа ничуть не ускоряется.
Поэтому гораздо интереснее было бы использовать flash не как эмуляцию диска, а именно как память, в качестве кэша, похоже на то, что описано выше.
При этом на SSD попадают «горячие», действительно активные данные, для которых использование Flash действительно дает максимум выигрыша.

Сейчас именно этот вариант активно развивается, в том числе как в «больших» дисковых массивах (NetApp FlashCache), так и в отдельных кэш-контроллерах(Adaptec MaxIQ).
Не стабильней, по крайней мере ReiserFS 3.6, которая давно в ядре.
Упаковка хвостов может помочь для экономии места при миллионах небольших файлов.
Я могу ошибаться, но миллионы небольших файлов это как раз то, чего стоит избегать.
К сожалению, это — та ситуация, которой никак не избежать.
Например если есть хостинг изображений.

Приведу пример. У меня есть небольшой хостинг изображений в провайдерском метронете (город и область), около 20-25 тысяч уникальных пользователей, просмотры не считаются, т.к. логи не ведем для снижения нагрузки, потому что всё железо — десктопное (проект частный, а не провайдерский).

Так вот, у нас около миллиона файлов (всего ~170 гб). Ещё миллион — на миниатюры (~30 гб).

// извините, могу комментировать только раз в 5 мин
btrfs тоже в ядре с версии 2.6.29.
Почему я не использовал ReiserFS:
1. Она не оптимизирована для работы с SSD и попрождает много лишних операций записи на диск (что увеличивает его износ)
2. У нее нет возможности делать раздел на нескольких дисках, тем более указывать где хранить метаданные.
3. Я не уверен какя система из ReiserFS и btrfs в режиме компресии экономичнее.

Речь идет только о кеше, система на сервере раздачи находиться на обычном HDD, поэтому в случае «падения кеша» я бы мог натянуть его заново.
> 1. Она не оптимизирована для работы с SSD и попрождает много лишних операций записи на диск (что увеличивает его износ)
> 2. У нее нет возможности делать раздел на нескольких дисках, тем более указывать где хранить метаданные.
> 3. Я не уверен какя система из ReiserFS и btrfs в режиме компресии экономичнее.

А не дешевле будет n сервера на SATA дисках с CARP или чем-то подобным?

Я не думаю что это будет более дешовое решение ни с точки зрения стоимости оборудования, ни с точки зрения размещения этого оборудования в датацентре.
Ну Dell 860 с 2 x 300 Гб дисками WD Raptor выйдет чуть дороже чем 4 SSD Intel X25-E SLC. Для SSD еще придется купить новый контроллер, который обойдется тысяч в 15-20, корпус. А потом еще эти диски года 2 при интенсивной загрузке проработают. Сможет ли даже SLC диск на частых записях выдержать хотя бы год?
У меня небыло ни одного падения на SSD-дисках. На btrfs я перешел не сразу, сначала все крутилось на ext4. Експерименты с btrfs я начал летом (т.е. речь идет максимум о полугодичной стабильной работе).
youtube решает эту проблему дешевле — рейд 10 сервера и картинки в биг тейбл, по тому что в обычной фс хранить не выгодно + кеш и распределенность из коробки
А не будет медленный раздел метаданных тормозить работу файловой системы. Я понимаю, что в btrfs это должно быть предусмотрено, но хотелось бы знать как именно.
Метаданные в btrfs «по умолчанию» хранятся на том же устройстве на котором сами данные, но принудительно вы можете их разнести по разным устройствам.
Если вы это делаете принудительно то это означает что если метаданные ложатся на медленное устройство то они читаются медленно.
Ну понятно, что метаданные читаться будут медленно. А будет ли это на производительность влиять? Может же btrfs сначала быстро отдать файл, а потом в фоне обновить мету или еще как.
У меня на сервере где раздаеться 300гб/день мелких файлов iowait 26,76 а на другом который раздает 2тб/день 6.
параметр noatime включает в себя nodiratime, более того, nodiratime даже не проверяется при наличии noatime :)
>>Абсолютно не повлияет на скорость раздачи апгрейд CPU, потому что «тормозит» не он! :)

Неверно, на скоростях порядка гигабита, процессор очень сильно играет роль. Так получалось добиваться +200Мбит с сервера просто заменив какой-то одноядерный селерон на E2160 ;)
Only those users with full accounts are able to leave comments. Log in, please.