LINUX.ORG.RU
ФорумAdmin

Правильно приготовить SSD

 ,


2

1

Как бы проверить правильно ли все выровнено и на всех ли уровнях (второй раздел наверное можно не учитывать, его не планируется использовать):

уровни представляются как-то так:

  SSD+SSD
   |
  MD RAID 1
   |
  EXT4

таблица разделов:

 % fdisk -l /dev/sda

Disk /dev/sda: 240.1 GB, 240057409536 bytes
32 heads, 32 sectors/track, 457873 cylinders
Units = cylinders of 1024 * 512 = 524288 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000977d2

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           3      454059   232476672+  fd  Linux raid autodetect
/dev/sda2          454059      457874     1953367+  fd  Linux raid autodetect
 % 
 % fdisk -lu /dev/sda

Disk /dev/sda: 240.1 GB, 240057409536 bytes
32 heads, 32 sectors/track, 457873 cylinders, total 468862128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000977d2

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   464955392   232476672+  fd  Linux raid autodetect
/dev/sda2       464955393   468862127     1953367+  fd  Linux raid autodetect
 % 

информация о диске из smartctl (оба одинаковые)

Model Family:     Intel 530 Series SSDs
Device Model:     INTEL SSDSC2BW240A4
Firmware Version: DC32
User Capacity:    240,057,409,536 bytes [240 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)

данные о массиве:

% cat /proc/mdstat 
Personalities : [raid0] [raid1] 
md1 : active raid1 sda1[0] sdb1[1]
      232476480 blocks super 1.0 [2/2] [UU]
      bitmap: 1/2 pages [4KB], 65536KB chunk

данные о фс:

 % dumpe2fs /dev/md1 | head -200
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          458225ff-580f-4e56-baeb-a5bf8d2e72b0
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              14532608
Block count:              58119120
Reserved block count:     2905956
Free blocks:              56966011
Free inodes:              14511793
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1010
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Mon Mar 24 21:31:05 2014
Last mount time:          Mon Mar 24 22:08:11 2014
Last write time:          Mon Mar 24 21:36:46 2014
Mount count:              4
Maximum mount count:      -1
Last checked:             Mon Mar 24 21:31:05 2014
Check interval:           0 (<none>)
Lifetime writes:          11 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       4065166
Default directory hash:   half_md4
Directory Hash Seed:      3088fcf6-c9e9-4b8b-8df0-a5a87dcbd547
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x0055757c
Journal start:            31832

Вопрос возник из-за низкой скорости mysql-slave сервера который работает на вышеописанной схеме (со стороны это выглядит как будто репликация не успевает за мастером упираясь в io), данные iostat со slave:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.03    0.00    0.08    4.32    0.00   95.57

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00   113.40    0.40  257.40     3.20  2904.40    11.28     1.28    4.97   3.58  92.38
sdb               0.00   113.40    0.00  257.20     0.00  2904.40    11.29     1.32    5.13   3.72  95.62
md1               0.00     0.00    0.40  365.00     3.20  2894.40     7.93     0.00    0.00   0.00   0.00

при этом на master-сервере все чудесно, не смотря на большую нагрузку на io, так же master-сервер имеет другие диски (intel SSD 320 (SSDSA2CW080G3)), которые вроде бы должны быть медленнее или я ошибаюсь?

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          13.35    0.00   16.97    2.12    0.00   67.56

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00   532.00    0.00  931.60     0.00 13365.80    14.35     0.31    0.33   0.12  11.58
sdb               0.00   532.00    1.40  931.60    20.80 13365.80    14.35     0.30    0.32   0.13  11.90
md1               0.00     0.00    1.40 1456.40    20.80 13366.40     9.18     0.00    0.00   0.00   0.00

★★★

оба одинаковые

и сдохнут одновременно. Не обманывай судьбу, бери 15к-оборотные диски.

anonymous
()

Intel 530 под БД? Чо с дуба рухнул или деньги жгут руки? Если страшные иопсы, бери Samsung SM843T или на крайняк Intel S3700. А если нищеброд или БД не очень страшная, то рейд из 10к/15к винтов еще никто не отменял.

Lordwind ★★★★★
()
Ответ на: комментарий от Lordwind

гм, а чем именно плох 530? если смотреть спецификацию

S3700 - 36000 IOPS
530 - 80000 IOPS

или это latency так плохо влияет? у 320 оно ниже всего на 5 µs кажется по сравнению с 530, но по остальным параметром оно проигрывает

dGhost ★★★
() автор топика
Ответ на: комментарий от dGhost

Тебе надо меньше думать о скорости и больше о долговечности SSD. Столько умного понаписал, а про ресурс ячеек ни слухом ни духом. Стыдно!

Lordwind ★★★★★
()
Ответ на: комментарий от Lordwind

Намекаете что 530 сдохнет в два раза быстрее 3700? Вангую что диск с 160000 иопсами сдохнет в два раза быстрее 530-го.

anonymous
()
Ответ на: комментарий от Lordwind

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

erzent ☆☆
()
Ответ на: комментарий от erzent

Так именно в продакшене и бывают не просто толстые базы, а высоконагруженные, вот тогда выбора и не остается. Но именно под базы ссд надо брать во-первых с очень продвинутым контроллером, который способен выполнять фоновую очистку мусора без участия ОС и TRIM (поэтому можно спокойно делать рейд), а во-вторых с очень могучим ресурсом, а это нынче или за счет eMLC или за счет большого объема (а лучше и то и другое). ТС думает что он самый хитрый и зеркало из консумерских ссд его спасет.

Lordwind ★★★★★
()
Ответ на: комментарий от Lordwind

в спецификации указано что 530 серия имеет ресурс в «5 years with typical client workload assuming up to 20 GB of host writes per day», этого вполне достаточно для текущий задачи

dGhost ★★★
() автор топика
Ответ на: комментарий от dGhost

typical client workload

Бог в помощь. На рейде без трима получишь на каждый IO перезапись куском в 256/512 кб и хоть завыравнивайся. Кстати глянул спеки...

SF-2281

Эталонное ссзб, можешь и дальше фапать на сферические иопсы из диванных обзоров

Lordwind ★★★★★
()
Ответ на: комментарий от Lordwind

Тебе надо меньше думать о скорости и больше о долговечности SSD. Столько умного понаписал, а про ресурс ячеек ни слухом ни духом. Стыдно!

тащем-то не факт, что ресурс имеет значение. Ячейки портяться только от записи, а вот сколько там записи — ТС не указал. Обычно в СУБД 95% это чтение. Причём это самое чтение отлично убивает HDD, а вот на SSD практически не влияет.

emulek
()
Ответ на: комментарий от erzent

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

тебе и не нужно с такими объёмами. (и если у тебя много рандомной записи)

emulek
()
Ответ на: комментарий от emulek

с каких пор смарт гарантирует безопасность или отказоустойчивость? или он уже научился предсказывать выход из строя с точностью 100%?

Lordwind ★★★★★
()
Ответ на: комментарий от emulek

Причём это самое чтение отлично убивает HDD, а вот на SSD практически не влияет

Любое устройство под нагрузкой это расходный материал, для HDD хотя бы можно N дисков положить на отказоустойчивость и N на полочку для замены. А вот купишь ты пару модных SSD, через пару лет один врежет дуба, а замену уже не найдешь. А если два сразу откинутся? Ну хочет ТС играть в рулетку, разве запрещает кто...

Lordwind ★★★★★
()
Ответ на: комментарий от Lordwind

с каких пор смарт гарантирует безопасность или отказоустойчивость? или он уже научился предсказывать выход из строя с точностью 100%?

не, 100% гарантии даёт только морг, но вот ты(вроде) тут выше про износ писал, так вот, SMART этот износ SSD умеет показывать в любых SSD(начиная от самых дешёвых). Потому, конечно случайные поломки (например контроллер сдохнет) возможны, но их вероятность НАМНОГО ниже, чем у HDD. Что касается износа, то его можно контролировать, и SSD штатно работает с ненулевым износом(со стороны системы просто плавно снижается скорость доступа).

Т.о. для сервера SSD более предпочтителен, если конечно не нужен большой объём и/или большой процент записи.

emulek
()
Ответ на: комментарий от Lordwind

Пока неликвид увы,нормальный ссд подобного уровня стоит больше 200 тонн,увы, но в рашке подобные траты пока не любят,пусть лучше на 20-30 сек дольше открывается страница или обрабатывается запрос

erzent ☆☆
()
Ответ на: комментарий от erzent

пусть лучше на 20-30 сек дольше открывается страница или обрабатывается запрос

Всего 20-30 сек. А если запросов туева куча? Сколько в итоге накапает?

roman77 ★★★★★
()
Ответ на: комментарий от roman77

если 20-30 секунд генерится страница, а таких страниц надо много, то это дерьмовая программа, и ssd тут вряд ли поможет, только спрячем немного тормозов, в лучшем случае.

anonymous
()
Ответ на: комментарий от erzent

на всех площадках плачут, ты невнимательно смотрел

anonymous
()
Ответ на: комментарий от Lordwind

Любое устройство под нагрузкой это расходный материал

согласен. Но нагрузка бывает разная, и убивает она по разному. SSD убить намного быстрее HDD несложно. Обратное тоже верно.

для HDD хотя бы можно N дисков положить на отказоустойчивость и N на полочку для замены.

там это внутри сделано. Т.е. в самом дешёвом SSD Over9000 резервных ячеек, которые на лету заменяют выбитые. Потому девайс получается более предсказуемый и как следствие — надёжный. Хотя конечно чудес не бывает, и за 2тыщи рублей продаётся такое же говно, что SSD, что и HDD.

А вот купишь ты пару модных SSD, через пару лет один врежет дуба, а замену уже не найдешь.

для HDD это точно также верно. Ну и через пару лет я оба выкину, и не важно, насколько они рабочие.

Ну хочет ТС играть в рулетку, разве запрещает кто...

ты сам сказал, что это расходник. Как туалетная бумага. Да, такая же непредсказуемая, если ты — дурак.

emulek
()
Ответ на: комментарий от anonymous

если 20-30 секунд генерится страница, а таких страниц надо много, то это дерьмовая программа

может это дерьмовая страница, за которую платят хорошие деньги.

emulek
()
Ответ на: комментарий от emulek

SMART этот износ SSD умеет показывать

смарт пока умеет только считать количество записанных данных, а уж на какое количество ячеек они пришлись это зависит от множества слабо контролируемых факторов и чем дальше отклоняться от предназначенной производителем ниши использования, тем больший рандом будет присутствовать

Lordwind ★★★★★
()
Ответ на: комментарий от erzent

ссд на 512 гб стоит как 2 винта по 4 тб,пока ссд глупость для продакшена в этом плане.

4tb диски научились выдавать по 40-50k iops при сервистаймах меньших 1-2мс? Или вас устраивают 10+ms по продовыми базами?

user_undefined
()
Ответ на: комментарий от erzent

я вообзе не понимаю пока зачем на ссд бд вешать

и не удивительно.

у меня базы данных по терабайту и больше

доооо, а у меня 28см в холодной воде.

512 гб стоит как 2 винта по 4 тб,пока ссд глупость для продакшена в этом плане.

уж сколько лет в хайлоаде используют, а наш иксперт всё неодобряет, нуну

anonymous
()
Ответ на: комментарий от anonymous

там и сд карты используют некоторые, но это не говорит о надёжности, вот когда сбер перейдёт на тб ссд, тогда будет разговор.

erzent ☆☆
()
Ответ на: комментарий от erzent

ам и сд карты используют некоторые,

это ты про свою шарагу или вообще просто так ляпнул? не видел ни в одной конторе такого бреда.

вот когда сбер перейдёт на тб ссд, тогда будет разговор.

это твой технологический эталон? у которого торги по 10 минут открываются? нуну

anonymous
()
Ответ на: комментарий от erzent

не приводи в пример дерьмо, в котором онлайновые платежи раз в месяц работают, а от площадок плюются самые терпеливые бабки

anonymous
()
Ответ на: комментарий от Lordwind

смарт пока умеет только считать количество записанных данных, а уж на какое количество ячеек они пришлись это зависит от множества слабо контролируемых факторов и чем дальше отклоняться от предназначенной производителем ниши использования, тем больший рандом будет присутствовать

что ты имеешь против рандома? Ты его боишься? У тебя фобия? Про закон больших чисел не знаешь?

Пойми простую вещь: если на SSD написано 120Гб, то на самом деле там 140Гб. Причём, если ты убьёшь рандомные 20Гб, то этого ну никак не заметишь, т.к. 120Гб у тебя останутся.

Дело в том, что когда ты пишешь на SSD 4К, то на самом деле ты пишешь по меньшей мере 5К, причём эти 5К равномерно размазываются по всему носителю.

emulek
()
Ответ на: комментарий от erzent

Для каких операций? Для какого-то ненужного объемного барахла - охотно верю, для карточного процессинга - вряд ли. У нас меньше чем у них транзакций проходит, но при 5мс уже начинаются жалобы, 10мс - уже критичный инцидент.

Хотя у нас не все на ssd, процентов 40% базы в ssd, остальное на 15k блинах

user_undefined
()
Ответ на: комментарий от dGhost

какие-то хитачевые 200 гиговые mlc, вроде как тошиба им оем дает, но тут могу и ошибаться

user_undefined
()
Ответ на: комментарий от emulek

Ты не вкурил драму. Если ОС поддерживает очистку (TRIM), ФС поддерживает очистку, контроллер поддерживает очистку и юзер такой простой что пишет последовательно большими блоками, но не забивает диск даже на 50%, то... ДА, реальный износ будет отличаться от данных смарта не более чем на 10%. Если есть рейд, нет фоновой очистки мусора, юзер пишет на диск рандомно малыми блоками и забивает диск под завязку, то смарт будет точнее рпедсказывать погоду на Марсе, чем состояние износа.

Повторяю 3й раз для тех кто без очков или слепой от рождения. Без трима и тем более на сандфорсе после первоначальной записи данных, любая перезапись будет вестись очень большими блоками, сейчас вроде 512 кб. В базе обновил одну запись, получи 512 кб. Обновился крохотный лог, получи 512 кб. А смарт будет считать именно те крошечки, что пишет ОС. И сдохнет диск при абсолютно здоровом смарте и очень быстро.

Lordwind ★★★★★
()
Ответ на: комментарий от Lordwind

Ты не вкурил драму.

И сдохнет диск при абсолютно здоровом смарте и очень быстро.

КСЖ. А почему IRL этого не наблюдается?

emulek
()
Ответ на: комментарий от nt_crasher

Смотря какая роль БД, если OLAP - то да, а вот в OLTP как раз запись в основном и идет.

в OLTP транзакции пакуются в блоки, и уже эти блоки пишутся. Я конечно не Ванга, но думаю, что тестирование в этом случае поможет. И не факт, что HDD тут будут лучше, всё зависит от конкретного юзкейса.

PS: ещё раз я не говорю, что SSD лучше во всём.

emulek
()
Ответ на: комментарий от emulek

Еще как наблюдается, на заре их пришествия, когда в eeepc ставили флеш-огрызки у массы народа они подыхали за полгода-год. А все потому что контроллеры были тупые. Сейчас поумнее стали, но как я сказал, чем дальше в лес, тем бесполезнее смарт. Вот у Линуса диск сдох, да так внезапно, что чуть релиз ядра не тормознули... Сейчас страсти поутихли чуток но только потому что функционал контроллеров покрывает 80-90% юзер кейсов и смарту можно в целом верить, хоть и осторожно, примерно как соседской бабушке. Базы и прочие извращения это оставшиеся 10%, про которые скорее по первому каналу объявят кончину диска, чем по смарту.

Lordwind ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.