Комментарии 69
с параметром iowait (процент простоя CPU в ожиданииТуда же относится ожидание ответа от сетевой подсистемы ввода-вывода.дисковыхопераций ввода/вывода)
А в целом за статью +, поделились полезным опытом.
Спасибо, поправил.
> Совсем скоро после публикации той статьи в нашей компании появился Kingston SNE125-S2/64GB на базе SSD Intel x25m
Вы ничего не путаете? SNE сделан на базе x25e.
Вы ничего не путаете? SNE сделан на базе x25e.
А какие у вас smart параметры после года использования?
Вот эти:
Код E1 – Host Writes
Код E9 – Media Wearout Indicator
Вот эти:
Код 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)
написано же — прошел год
При експерименте ни один из 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» это «десять лет» в английском.
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 за те же деньги.
точнее доходил.
Как ПРАВИЛЬНО победить задержки раздачи файлов для обычного сайта.
решение номер 1 —
Когда у вас спросят — сколько памяти ставить в новый сервер 2 или 4 гига — скажите «ставьте 16»
Лично у меня вся статика занимает ну максимум гигов 6. И я уверен — она всегда будет браться из кеша.
решение номер 2 —
NCQ, AIO и другие механизмы которые позволяют отдать больше файлов большему количеству клиентов с большими задержками.
Да именно что с большими — если системе надо будет подождать пару секунд чтобы жесткий более непрерывно выполнил свою работу — это позволит обработать СИЛЬНО большее количество клиентов ценой появления маленьких задержек. Ну и чем меньше клиентов тем меньше задержек
если же у вас файлопомойка и у вас много много файлов — вас окончательно не спасет никакое решение. Потому что решение которое вас спасет — себя просто не окупит
ПС: да, я абсолютно уверен что массив из обычных дисков + куча рама более эффективен чем ssd за те же деньги.
В статье написано, что размер кеша — 200G. Это примерно $1000 как ssd и раз в 10 дороже в виде ram.
Окей, вопрос номер два — что такое cache-hit, cache-miss и мифический «плоский»(равномерно-рандомный) вариант доступа к данным. Когда запрашиваются вроде как все, но вроде как один-два раза в день.
Так что путаем размер кеша и размер активно используемого кеша.
Когда я работал в викимапии система рендера тайлов сильно упиралась именно в «плоский» вариант доступа к данным. Иногда было быстрее не брать данные из кеша, а сгенерить их на месте чем просто поискать их в кеше и вернуть.
Но там кем был не 200G и даже не 2000G.
Так что путаем размер кеша и размер активно используемого кеша.
Когда я работал в викимапии система рендера тайлов сильно упиралась именно в «плоский» вариант доступа к данным. Иногда было быстрее не брать данные из кеша, а сгенерить их на месте чем просто поискать их в кеше и вернуть.
Но там кем был не 200G и даже не 2000G.
Вы наверное не обратили внимание, что первое что я бы апгрейдил — это имеено RAM, но не во всякую материнку можно поставить более 16G кеша. Кроме того если у Вас все фотки помещаются в 6G и Ваш сайт растет то это означает что когда нибудь Ваши 16G тоже Вас не спасут :)
> nodatacow
Почему?
Почему?
Вот мы и подошли к самой интересной возможности btrfs: это создавать софтовые RAID-масыви и указывать явным образом, на каких дисках сохранять данные на каких метаданные
Что произойдет при «вылетании» диска с метаданными? Данные будут доступны при обычном монтировании диска?
Что произойдет при «вылетании» диска с метаданными? Данные будут доступны при обычном монтировании диска?
Пришла подсказка из зала, цитирую:
"
я сам писал статьи на эти темы еще лет 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
"
я сам писал статьи на эти темы еще лет 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
«Сейчас уже доступны диски, использующие технология SLC (Single-Level Cell) с «умным» конроллером.»
Вообщето изначально были доступны только SLC диски, MLC появились позже.
кроме того 100000 циклов перезаписи котороые приписываются SLC ячейкам сильно завышены.
Вообщето изначально были доступны только SLC диски, MLC появились позже.
кроме того 100000 циклов перезаписи котороые приписываются SLC ячейкам сильно завышены.
Ваши сведения устарели. В области SSD все меняется к лучшему очень быстро. Сегодня ситуация с количеством циклов у современных SLC SSD в реальной жизни практически равна такой у HDD.
blog.aboutnetapp.ru/archives/669
blog.aboutnetapp.ru/archives/669
вы путаете рекламируемое время жизни (MTBF) ssd по сравнению с hdd с количеством перезаписи одной ячейки. Интел например в последнем интеловском написано «1 петабайт рандомной записи за время жизни винта» для 32Г модели. если у вас полвинта занято и остальное перезаписывается регулярно это будет уже только 512 терабайт за время жизни и тд. При неслучайной записи до петабайта будет ой как далеко.
но даже петабайт при скорости 170 мегабайт в сек запишутся за 73 дня, что гораздо меньше 2 миллионов часов MTFB
но даже петабайт при скорости 170 мегабайт в сек запишутся за 73 дня, что гораздо меньше 2 миллионов часов MTFB
Вы правда считаете, что я не различаю разницу между «MTBF» и реальным положением дел? ;)
Цитаты по ссылке, приведенной выше, это мнения админов-практиков, эксплуатирующих системы с деcятками и сотнями SSD.
Цитаты по ссылке, приведенной выше, это мнения админов-практиков, эксплуатирующих системы с деcятками и сотнями SSD.
все зависит от типа нагрузок, у меня например четыре интеловских SSD купленых для кеша полгода назад (нужна быстрая запись и паралельное чтение) уже показывают по паре десятков реаллоков, причем реально за эти полгода винты работали месяца три. Соответственно если мы пустим их из тестовой нагрузки в полную выйдут из строя за год (при этом они конечно себя окупят, но надо расчитывать время на даунтайм что тоже расходы)
С другой стороны у нас есть 4 15K SAS винта с чуть меньшей (процентов на 15) загрузкой на запись, но им уже по три года и до сих пор ни одного реаллока.
С другой стороны у нас есть 4 15K SAS винта с чуть меньшей (процентов на 15) загрузкой на запись, но им уже по три года и до сих пор ни одного реаллока.
«SLC с «умным» конроллером» от Intel появились в 2008 году. Нащет 100000 циклов не проверял, возможно єто маркетинговый ход.
Когда картинок очень много столкнулись с большим увеличением iowait с некоторой периодичностью. Как оказалось, следует отключить updatedb.
А как вы смотрите на размещение СУБД на SSD?
По моим наблюдениям она у нас даёт основную нагрузку на io
По моим наблюдениям она у нас даёт основную нагрузку на io
Для базы данных я бы все же использовал RAID-массив из SAS-дисков. База данных породит намного больше трафика на запись.
Почему-то мне кажется, что современные SSD типа OCZ Vertex 2 очень умные и «размазывают» циклы записи по всем ячейкам памяти. Т.е. мереть как мухи под записью не должны.
И именно для СУБД применний SSD-диск кажется мне наиболее привлекательным
И именно для СУБД применний SSD-диск кажется мне наиболее привлекательным
Мой знакомый собрал в RAID 4 обычных MLC SSD в аппаратный RAID на хостинговый сервак с LAMP системой. Они продержались 4 месяца и умерли практически одновременно. Это было год назад, возможно современные Vertex-ы продержались бы больше.
Для базы данных одним из самых ускоряющих факторов является кеш RAID-контроллера на запись.
У некотрых контроллеров Areca есть возможность в контроллер установить 4Gb кеш, вот это действительно дает уменьшене iowait.
Для базы данных одним из самых ускоряющих факторов является кеш RAID-контроллера на запись.
У некотрых контроллеров Areca есть возможность в контроллер установить 4Gb кеш, вот это действительно дает уменьшене iowait.
Тут вот еще про что не стоит забывать. Для _хранения_ SSD вообще, в принципе, не очень экономически эффективен.
Какая часть вашей базы активно считывается и записывается в течение дня? 10%? 30%? Вряд ли сильно больше. Значит от 90 до 70% данных базы просто лежат занимая сверхдорогое пространство SSD, как они могли бы замечательно лежать на SATA за 80$, и от того, что они находятся на SSD, общая работа ничуть не ускоряется.
Поэтому гораздо интереснее было бы использовать flash не как эмуляцию диска, а именно как память, в качестве кэша, похоже на то, что описано выше.
При этом на SSD попадают «горячие», действительно активные данные, для которых использование Flash действительно дает максимум выигрыша.
Сейчас именно этот вариант активно развивается, в том числе как в «больших» дисковых массивах (NetApp FlashCache), так и в отдельных кэш-контроллерах(Adaptec MaxIQ).
Какая часть вашей базы активно считывается и записывается в течение дня? 10%? 30%? Вряд ли сильно больше. Значит от 90 до 70% данных базы просто лежат занимая сверхдорогое пространство SSD, как они могли бы замечательно лежать на SATA за 80$, и от того, что они находятся на SSD, общая работа ничуть не ускоряется.
Поэтому гораздо интереснее было бы использовать flash не как эмуляцию диска, а именно как память, в качестве кэша, похоже на то, что описано выше.
При этом на SSD попадают «горячие», действительно активные данные, для которых использование Flash действительно дает максимум выигрыша.
Сейчас именно этот вариант активно развивается, в том числе как в «больших» дисковых массивах (NetApp FlashCache), так и в отдельных кэш-контроллерах(Adaptec MaxIQ).
Насколько btrfs стабильнее reiserfs?
Не стабильней, по крайней мере ReiserFS 3.6, которая давно в ядре.
Упаковка хвостов может помочь для экономии места при миллионах небольших файлов.
Упаковка хвостов может помочь для экономии места при миллионах небольших файлов.
Я могу ошибаться, но миллионы небольших файлов это как раз то, чего стоит избегать.
К сожалению, это — та ситуация, которой никак не избежать.
Например если есть хостинг изображений.
Приведу пример. У меня есть небольшой хостинг изображений в провайдерском метронете (город и область), около 20-25 тысяч уникальных пользователей, просмотры не считаются, т.к. логи не ведем для снижения нагрузки, потому что всё железо — десктопное (проект частный, а не провайдерский).
Так вот, у нас около миллиона файлов (всего ~170 гб). Ещё миллион — на миниатюры (~30 гб).
// извините, могу комментировать только раз в 5 мин
Например если есть хостинг изображений.
Приведу пример. У меня есть небольшой хостинг изображений в провайдерском метронете (город и область), около 20-25 тысяч уникальных пользователей, просмотры не считаются, т.к. логи не ведем для снижения нагрузки, потому что всё железо — десктопное (проект частный, а не провайдерский).
Так вот, у нас около миллиона файлов (всего ~170 гб). Ещё миллион — на миниатюры (~30 гб).
// извините, могу комментировать только раз в 5 мин
btrfs тоже в ядре с версии 2.6.29.
Почему я не использовал ReiserFS:
1. Она не оптимизирована для работы с SSD и попрождает много лишних операций записи на диск (что увеличивает его износ)
2. У нее нет возможности делать раздел на нескольких дисках, тем более указывать где хранить метаданные.
3. Я не уверен какя система из ReiserFS и btrfs в режиме компресии экономичнее.
Речь идет только о кеше, система на сервере раздачи находиться на обычном HDD, поэтому в случае «падения кеша» я бы мог натянуть его заново.
Почему я не использовал ReiserFS:
1. Она не оптимизирована для работы с SSD и попрождает много лишних операций записи на диск (что увеличивает его износ)
2. У нее нет возможности делать раздел на нескольких дисках, тем более указывать где хранить метаданные.
3. Я не уверен какя система из ReiserFS и btrfs в режиме компресии экономичнее.
Речь идет только о кеше, система на сервере раздачи находиться на обычном HDD, поэтому в случае «падения кеша» я бы мог натянуть его заново.
> 1. Она не оптимизирована для работы с SSD и попрождает много лишних операций записи на диск (что увеличивает его износ)
> 2. У нее нет возможности делать раздел на нескольких дисках, тем более указывать где хранить метаданные.
> 3. Я не уверен какя система из ReiserFS и btrfs в режиме компресии экономичнее.
А не дешевле будет n сервера на SATA дисках с CARP или чем-то подобным?
> 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 это должно быть предусмотрено, но хотелось бы знать как именно.
У меня на сервере где раздаеться 300гб/день мелких файлов iowait 26,76 а на другом который раздает 2тб/день 6.
параметр noatime включает в себя nodiratime, более того, nodiratime даже не проверяется при наличии noatime :)
кто поздскажет как посмотреть износ SSD под linux?
MS_NOATIME implies MS_NODIRATIME.
>>Абсолютно не повлияет на скорость раздачи апгрейд CPU, потому что «тормозит» не он! :)
Неверно, на скоростях порядка гигабита, процессор очень сильно играет роль. Так получалось добиваться +200Мбит с сервера просто заменив какой-то одноядерный селерон на E2160 ;)
Неверно, на скоростях порядка гигабита, процессор очень сильно играет роль. Так получалось добиваться +200Мбит с сервера просто заменив какой-то одноядерный селерон на E2160 ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ускоряем раздачу фоток