Перейти к содержимому
Калькуляторы

SSD + mdadm

Привет!

Есть один сервер на Debain 7 (ядро 3.2.0-4). На нем крутится БД mysql, лежащая на SSD (Intel DC S3700). Требуется заменить SSD  по причине нехватки емкости и большой наработки (почти 3 года). И тут возник вопрос. Если собрать из двух SSD (DC S3610) зеркало на md, то как будут обстоять дела с TRIM? Если мне не изменяет память, то через md вообще не передается TRIM на диски (возможно я ошибаюсь). В общем, есть ли у кого-то опыт эксплуатации SSD (не важно, Intel или нет) в md RAID и как они себя там ведут? И как себя ведут диски при отключенном или не передающемся TRIM?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
55 minutes ago, megahertz0 said:

через md вообще не передается TRIM на диски

Передаётся. Не скажу правда за 3.2 ядро, но в нынешних передаётся точно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, megahertz0 сказал:

Требуется заменить SSD  по причине нехватки емкости и большой наработки (почти 3 года).

У SSD есть ключевой показатель Media Wearout Indicator, показывающий остаточный ресурс записи в %, посмотреть можно с помощью smartctl -a /dev/sda | grep Wearout.
Ресурс записи измеряют в TBW и отражают в документации.
Для Intel S3700 (хорошая серия) в доке пишут про:

Endurance: 10 drive writes per day for 5 years

https://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/ssd-dc-s3700-spec.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
37 минут назад, anix сказал:

У SSD есть ключевой показатель Media Wearout Indicator, показывающий остаточный ресурс записи в %, посмотреть можно с помощью smartctl -a /dev/sda | grep Wearout.
 

Это ОЧЕНЬ зависит от модели SSD... Каждый производитель тут себе сам придумывает чтото..  У меня вот нет Wearout, но есть 


smartctl -l ssd /dev/sdc
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.15.17-200.fc26.x86_64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

Device Statistics (GP Log 0x04)
Page  Offset Size        Value Flags Description
0x07  =====  =               =  ===  == Solid State Device Statistics (rev 1) ==
0x07  0x008  1               0  N--  Percentage Used Endurance Indicator

Это 0%, но у меня есть SSD со 170% использования и ничего, работает себе.. смерть на подобной наступила на 220% гдето..

 

Есть гдето в запасе SSD и без того и без другого..Но там были какието косвенные параметры, сейчас такие не стоят нигде у меня, чтобы быстро глянуть..

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну, на счет ресурса согласен.  DC S3700 вообще очень живучие SSD. У меня на одном из них лежит БД Заббикса, где-то 70 ГБ.  За 3 года записано почти 500 ТБ данных и работает он в основном на запись:

Скрытый текст

megahertz@zabbix:~$ sudo smartctl -a /dev/sdc
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Intel 730 and DC S35x0/3610/3700 Series SSDs
Device Model:     INTEL SSDSC2BA100G3
Serial Number:    BTTV33540A1W100FGN
LU WWN Device Id: 5 5cd2e4 04b47c73f
Firmware Version: 5DV10265
User Capacity:    100 030 242 816 bytes [100 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 2.6, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Wed May 16 19:51:35 2018 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                (    0) seconds.
Offline data collection
capabilities:                    (0x79) SMART execute Offline immediate.
                                        No Auto Offline data collection support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   1) minutes.
Extended self-test routine
recommended polling time:        (   2) minutes.
Conveyance self-test routine
recommended polling time:        (   2) minutes.
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0032   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       36280
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       43
170 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
171 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
174 Unsafe_Shutdown_Count   0x0032   100   100   000    Old_age   Always       -       37
175 Power_Loss_Cap_Test     0x0033   100   100   010    Pre-fail  Always       -       651 (215 2368)
183 SATA_Downshift_Count    0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0033   100   100   090    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
190 Temperature_Case        0x0022   081   073   000    Old_age   Always       -       19 (Min/Max 14/39)
192 Unsafe_Shutdown_Count   0x0032   100   100   000    Old_age   Always       -       37
194 Temperature_Internal    0x0022   100   100   000    Old_age   Always       -       19
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
225 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       15102791
226 Workld_Media_Wear_Indic 0x0032   100   100   000    Old_age   Always       -       12237
227 Workld_Host_Reads_Perc  0x0032   100   100   000    Old_age   Always       -       18
228 Workload_Minutes        0x0032   100   100   000    Old_age   Always       -       1907456
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
233 Media_Wearout_Indicator 0x0032   087   087   000    Old_age   Always       -       0
234 Thermal_Throttle        0x0032   100   100   000    Old_age   Always       -       0/0
241 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       15102791
242 Host_Reads_32MiB        0x0032   100   100   000    Old_age   Always       -       2963408

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

 

Тут вопрос в том как передается TRIM через md если md по сути фиолетово что за ФС на нем, а TRIM выполняется на основе данных ФС о свободных блоках. И самое главное. Что будет если диск активно напрягать на запись (как на примере), но при этом не делать TRIM вообще.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ну на центоси от 7.2 (откуда начиная вопрос у нас был актуален, скорее всего и раньше) через MD трим проходит.. не без приколов.. рейд 0 и 1 (и соотвественно 10) нормально, а вот 5, (ну и 3 и 6, т.к. там один обработчик) нужно 1 поставить в sysctl, но дальше, они впендюрили белый список поддерживаемых устройств, которые возвращают нужные значения (не помню, нули кажется) после трима, типа бывают устройства, которые возвращают чтото другое и это им ломало логику.. вместо черного списка там белый, ну и как назло наши SSD возвращали, если проверить, потримить и почитать потом сектора, то, что надо, но в списке их небыло. и хрен. (понятно что можно было бы пересобрать модуль, дописав нужные названия в список, но решили другим методом, список, как это не странно, не в модуле рейда, а в модуле контроллера, смена контроллера волшебным образом проблему решила с теми же самыми SSD и тем же самым рейдом.

 

И цифры по скорости записи, чтобы там не трендели производители серверных железок, говорят за то, что трим делать надо.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это зависит от ФС которая поверх mdadm. Чтобы включить trim для ext4, нужно добавить опцию discard в опции монтирования.

В десятке серверов стоят DC3500, года три как без сбоев.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 hour ago, EugeneP said:

Это зависит от ФС которая поверх mdadm.

Вопрос у автора поддерживает ли mdadm пропуск TRIM в принципе.

 

1 hour ago, EugeneP said:

Чтобы включить trim для ext4, нужно добавить опцию discard в опции монтирования.

Это чтобы включить автоматический TRIM выполняемый самой ФС. Но это не рекомендуется делать, в том числе и разработчиками самой ФС тоже -- с точки зрения надёжности (у ряда SSD имеются разные мутные глюки с отработкой TRIM) и производительности (зачастую это не-queued операция, т.е. на всё её время обрабатываемые IOPS падают до нуля). Текущая рекомендация - опцию discard не использовать, вместо этого в crontab поставить запуск программы fstrim для этой ФС на ~раз в сутки, в период наименьшей нагрузки. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Но если ССД большая и свободного места много, то fstrim ставить раком будет довольно на долго систему..  если система активно используется 24*7 то.. в общем местами мы включили TRIM на монтировании. Тогда оно тримит только то, что стерло, а не весь тер скопом. в нашем случае это оказалось меньшим злом. Но да, лучше бы таки fstrim переодический, но не всегда приемлемо..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нормальные серверные SSD диски имеют размер меньше "круглого", например, 200 а не 256 и вот на таких вообще можно не заботиться о Trim - там всегда есть пул чистых страниц для быстрой записи. Ну раз в год можно дать команду fstrim

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

А раз в год или раз в неделю это от объема записи записи зависит.. у меня есть одна машинка где за год с небольшой мелочью в те 220% (smartctl -l ssd) утерлась ССД 200Г размером, где ниразу больше 10Г одновременно занято и небыло.. но и трима ниразу небыло, т.к рейд контроллер и он ни в JBOD ни как еще трим не пропускает.  теперь там 500, но даже посмотреть то нельзя сколько натерло....

500Г ССД под базой от забикса утерлась в 100% через год и пару месяцев, потом резко снизили объемы записи  и вот уже прошло еще полтора года и теперь там 170%.. как бы от забикса принято решение отказываться. помрет, вот и откажемся :) Но пока работает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 hours ago, st_re said:

Но если ССД большая и свободного места много, то fstrim ставить раком будет довольно на долго систему

Зависит ещё от ФС. Ext4 например запоминает уже тримнутые области (discard'ом или fstrim), и при повторных вызовах fstrim их больше не тримает. A Btrfs не запоминает. Не знаю насчёт XFS/JFS.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

xfs, судя по времени трима, тримает все свободное всегда..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
12 hours ago, st_re said:

судя по времени

Можно смотреть fstrim -v, на Ext4 при повторных вызовах сразу же после первого (и без записи на ФС) она возвращает "0 байт trimmed". А на других ФС всегда полное кол-во свободного места (и дольше, конечно).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

ну да, вот  прямо сейчас 2 раза подрял. xfs

$ sudo fstrim -v -a
/home: 286,6 GiB (307678965760 bytes) trimmed
$ sudo fstrim -v -a
/home: 286,6 GiB (307677859840 bytes) trimmed
 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Собрал в общем схему с md поверх SSD. В итоге fstrim через md до диска не доходит:

root@hs1:/home/megahertz# mount /dev/md2p1 /mnt/s3600/
root@hs1:/home/megahertz# fstrim -v /mnt/s3600/
fstrim: /mnt/s3600/: FITRIM ioctl failed: Неподдерживаемая операция

По крайней мере на Debian 7 и ядре 3.2.68-1.

А еще попробовал погонять fio на голом диске и на диске за md (raid 1) с целью изучить падение производительности на md. Сразу оговорюсь, что SSD подключен через SATA-II, поэтому bandwidth ограничен 3 Gbps.

 

Голый диск:

Скрытый текст

root@hs1:/home/megahertz/fio# fio config.ini
readtest: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=16
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=16
2.0.8
Starting 2 processes
^Cbs: 2 (f=2): [rw] [5.1% done] [171.4M/154.7M /s] [43.9K/39.6K iops] [eta 47m:38s]
fio: terminating on signal 2

readtest: (groupid=0, jobs=1): err= 0: pid=31388
  read : io=26028MB, bw=174666KB/s, iops=43666 , runt=152595msec
    slat (usec): min=1 , max=321 , avg= 3.35, stdev= 1.60
    clat (usec): min=32 , max=300184 , avg=362.14, stdev=1564.84
     lat (usec): min=35 , max=300197 , avg=365.61, stdev=1564.86
    clat percentiles (usec):
     |  1.00th=[  104],  5.00th=[  161], 10.00th=[  191], 20.00th=[  227],
     | 30.00th=[  258], 40.00th=[  290], 50.00th=[  318], 60.00th=[  346],
     | 70.00th=[  374], 80.00th=[  410], 90.00th=[  466], 95.00th=[  548],
     | 99.00th=[ 1160], 99.50th=[ 2024], 99.90th=[ 3536], 99.95th=[ 3856],
     | 99.99th=[99840]
    bw (KB/s)  : min=66404, max=248888, per=100.00%, avg=175082.83, stdev=13247.14
    lat (usec) : 50=0.02%, 100=0.81%, 250=26.35%, 500=65.72%, 750=5.23%
    lat (usec) : 1000=0.68%
    lat (msec) : 2=0.68%, 4=0.47%, 10=0.02%, 50=0.01%, 100=0.01%
    lat (msec) : 250=0.02%, 500=0.01%
  cpu          : usr=8.02%, sys=25.55%, ctx=5839144, majf=0, minf=38
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=6663284/w=0/d=0, short=r=0/w=0/d=0
writetest: (groupid=0, jobs=1): err= 0: pid=31389
  write: io=23215MB, bw=155794KB/s, iops=38948 , runt=152584msec
    slat (usec): min=1 , max=365 , avg= 3.63, stdev= 1.68
    clat (usec): min=47 , max=297194 , avg=406.22, stdev=1434.24
     lat (usec): min=51 , max=297197 , avg=409.97, stdev=1434.24
    clat percentiles (usec):
     |  1.00th=[  114],  5.00th=[  199], 10.00th=[  251], 20.00th=[  310],
     | 30.00th=[  342], 40.00th=[  362], 50.00th=[  386], 60.00th=[  414],
     | 70.00th=[  446], 80.00th=[  482], 90.00th=[  524], 95.00th=[  556],
     | 99.00th=[  604], 99.50th=[  628], 99.90th=[  684], 99.95th=[  716],
     | 99.99th=[99840]
    bw (KB/s)  : min=113448, max=221672, per=100.00%, avg=155943.88, stdev=8628.31
    lat (usec) : 50=0.01%, 100=0.45%, 250=9.52%, 500=74.91%, 750=15.08%
    lat (usec) : 1000=0.01%
    lat (msec) : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.01%
    lat (msec) : 100=0.01%, 250=0.02%, 500=0.01%
  cpu          : usr=8.48%, sys=24.14%, ctx=5808761, majf=0, minf=23
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=5942912/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=26028MB, aggrb=174665KB/s, minb=174665KB/s, maxb=174665KB/s, mint=152595msec, maxt=152595msec
  WRITE: io=23215MB, aggrb=155793KB/s, minb=155793KB/s, maxb=155793KB/s, mint=152584msec, maxt=152584msec

Disk stats (read/write):
  sdh: ios=6657262/5937504, merge=0/0, ticks=2398256/2397736, in_queue=4796996, util=100.00%

 

И за md:

Скрытый текст

root@hs1:/home/megahertz/fio# fio config.ini
readtest: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=16
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=16
2.0.8
Starting 2 processes
^Cbs: 2 (f=2): [rw] [5.2% done] [209.1M/89564K /s] [53.8K/22.4K iops] [eta 57m:15s]
fio: terminating on signal 2

readtest: (groupid=0, jobs=1): err= 0: pid=25571
  read : io=32171MB, bw=175172KB/s, iops=43792 , runt=188064msec
    slat (usec): min=1 , max=441 , avg= 2.85, stdev= 1.22
    clat (usec): min=29 , max=300177 , avg=361.64, stdev=3926.21
     lat (usec): min=32 , max=300183 , avg=364.59, stdev=3926.23
    clat percentiles (usec):
     |  1.00th=[   65],  5.00th=[   91], 10.00th=[  104], 20.00th=[  131],
     | 30.00th=[  155], 40.00th=[  177], 50.00th=[  199], 60.00th=[  223],
     | 70.00th=[  247], 80.00th=[  278], 90.00th=[  330], 95.00th=[  374],
     | 99.00th=[  474], 99.50th=[  564], 99.90th=[99840], 99.95th=[99840],
     | 99.99th=[100864]
    bw (KB/s)  : min=41412, max=287160, per=100.00%, avg=176469.72, stdev=41962.15
    lat (usec) : 50=0.18%, 100=7.97%, 250=63.11%, 500=27.99%, 750=0.45%
    lat (usec) : 1000=0.05%
    lat (msec) : 2=0.04%, 4=0.03%, 10=0.01%, 20=0.01%, 50=0.02%
    lat (msec) : 100=0.03%, 250=0.11%, 500=0.01%
  cpu          : usr=6.80%, sys=26.85%, ctx=7263969, majf=0, minf=39
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=8235871/w=0/d=0, short=r=0/w=0/d=0
writetest: (groupid=0, jobs=1): err= 0: pid=25572
  write: io=23751MB, bw=129325KB/s, iops=32331 , runt=188058msec
    slat (usec): min=1 , max=474 , avg= 2.40, stdev= 0.86
    clat (usec): min=23 , max=300389 , avg=491.61, stdev=5854.64
     lat (usec): min=49 , max=300393 , avg=494.11, stdev=5854.65
    clat percentiles (usec):
     |  1.00th=[   77],  5.00th=[  101], 10.00th=[  122], 20.00th=[  151],
     | 30.00th=[  177], 40.00th=[  203], 50.00th=[  227], 60.00th=[  253],
     | 70.00th=[  282], 80.00th=[  318], 90.00th=[  374], 95.00th=[  434],
     | 99.00th=[  548], 99.50th=[  580], 99.90th=[99840], 99.95th=[100864],
     | 99.99th=[199680]
    bw (KB/s)  : min=30885, max=242208, per=100.00%, avg=130981.28, stdev=35490.97
    lat (usec) : 50=0.01%, 100=3.74%, 250=55.28%, 500=38.85%, 750=1.88%
    lat (usec) : 1000=0.01%
    lat (msec) : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.01%
    lat (msec) : 100=0.02%, 250=0.18%, 500=0.01%
  cpu          : usr=6.51%, sys=18.09%, ctx=5826033, majf=0, minf=24
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=6080150/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=32171MB, aggrb=175171KB/s, minb=175171KB/s, maxb=175171KB/s, mint=188064msec, maxt=188064msec
  WRITE: io=23751MB, aggrb=129324KB/s, minb=129324KB/s, maxb=129324KB/s, mint=188058msec, maxt=188058msec

Disk stats (read/write):
    md2: ios=8231265/6079150, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=8236023/6080151, aggrmerge=1066/0, aggrticks=2951188/2951720, aggrin_queue=5910712, aggrutil=100.00%
  sdh: ios=8236023/6080151, merge=1066/0, ticks=2951188/2951720, in_queue=5910712, util=100.00%

 

Итого получается, что при чтении md не особенно влияет на bandwidth, но все таки  несколько ухудшает ее. Но, похоже, в пределах погрешности. Latency в среднем не меняется, но стандартное отклонение заметно выше на md.

На запись все примерно так же.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
19 minutes ago, megahertz0 said:

По крайней мере на Debian 7 и ядре 3.2.68-1.

Таки да, это добавили с ядра 3.7: https://kernelnewbies.org/Linux_3.7#Block

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, megahertz0 сказал:

обрал в общем схему с md поверх SSD. В итоге fstrim через md до диска не доходит:


root@hs1:/home/megahertz# mount /dev/md2p1 /mnt/s3600/
root@hs1:/home/megahertz# fstrim -v /mnt/s3600/
fstrim: /mnt/s3600/: FITRIM ioctl failed: Неподдерживаемая операция

 

echo "options raid10 devices_discard_performance=Y" > /etc/modprobe.d/md-raid10.conf    # для RAID0 и RAID1
echo "options raid456 devices_handle_discard_safely=Y" > /etc/modprobe.d/raid456.conf # для RAID 4, 5 или 6

???

(применяется при загрузке)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 5/18/2018 в 21:38, st_re сказал:

Наши тесты говорят, что для всех нашиих надо... скорость записи просаживается через некоторе время, если трим не делать. Когда сделаешь, снова ровно. :)

речь именно про серверные диски?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну у производителя заявлялось, что серверное... но, честно, сэкономили и ничего сильно дорогого не брали, больно на требуемых объемах из бюджета вываливались. Скорее всего бывает лучше.  Я же там написал, "для наших" :)

 

В общем  я имел в виду, что перед запуском в продакшн тестировать надо на вашй нагрузке ваши ССД, а не проспекты читать. Если тесты покажут, что трим не нужен, то слава кпсс... А вот если производитель наобещает горы золотые, то их, внезапно, может не оказаться там... Сюрприз будет.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
6 hours ago, st_re said:

Если тесты покажут, что трим не нужен, то слава кпсс...

Нужен, хотя бы с т.з. долговечности. Да и вообще если нет непреодолимых препятствий его использовать, эксплуатировать без него - всё равно что ездить на автомобиле у которого что-то стучит в двигателе.

А в данном случае таких препятствий нет, для Debian 7 штатно доступно более новое ядро 3.16:

https://packages.debian.org/wheezy-backports/linux-image-3.16.0-0.bpo.4-amd64

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, rm_ сказал:

А в данном случае таких препятствий нет, для Debian 7 штатно доступно более новое ядро 3.16:

Backports - это не совсем штатно. Даже, наверное, совсем не штатно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
38 minutes ago, snvoronkov said:

Backports - это не совсем штатно. Даже, наверное, совсем не штатно.

Штатно enough :), на порядок штатнее чем собирать самому.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот какой итог получается. Обновил систему на Debian 8, ядро 3.16.56-1+deb8u1. SSD собрал в зеркало. Разметил на массиве раздел, отформатировал его в ext4 без какой-то особой магии и смонтировал.

 

fstrim вроде выполнился:

root@hs1:/home/megahertz# fstrim -v /var/lib/mysql
/var/lib/mysql: 368,7 GiB (395904679936 bytes) trimmed

Похоже и правда начиная с Debian 8 md научился пропускать fstrim до дисков.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, megahertz0 сказал:

Похоже и правда

blktrace -d /dev/sda -a discard -o - | blkparse -i -

посмотрите, долетает ли до sda..

 

ну или записать кучу заранее известного мусора,найти её физически на sdX чтобы она DD отдавалась, стереть файл, сказать трим, сбросить кеши (echo 1 > /proc/sys/vm/drop_caches) и почитать оттуда же.. на большинстве SSD приедут нули, если трим сработал.. или тоже самое что было записано, если не сработал..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас