LINUX.ORG.RU
ФорумAdmin

Производительность SSD против жесткого диска? на ssd поиск занимает 100 мс, на жестком диске 3000-6000 мс

 


0

3

Производительность SSD против жесткого диска? на SD поиск занимает 100 мс, на HD 3000-6000 мс Можно ли оптимизировать производительность на жестком диске?

130 миллионов записей. 150 гб текста.

Один сервер. Пробовал разное количество сегментов и узлов (используя docker compose). Я пробовал разные варианты, но производительность на жестком диске намного хуже.

Я даже пытался отключить «refresh_interval»: «-1», force_merge

Каковы способы повышения производительности жесткого диска?

Ответ на: комментарий от Gonzo

Запланированно умереть? Или это была минутка философии?

Не осилили v2.0? Ещё раз, у ssd вполне конкретный счетчик, он из коробки заложен, записали в ячейку N-раз и всё, больше не могем.

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

Так лучше знать, когда девайс накроется, чем не знать.

Это только про запланировано накроется, а может и внезапно же. Ну и ещё нюанс, далеко не все отдают в смарте эту инфу, видимо что бы не нервировать пользователей :)

Ну и у меня за последние 20 лет сдохло 3 HDD и ни одного SSD.

Я так понимаю вы про личные девайсы? Ну и «статистика баба продажная». В каком году у вас появился первый ssd? Какая технология использовалась? (ssd, ssd рознь). Хто производитель?
В части характеристик к hdd почти такие же вопросы, производитель + год выпуска.

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

Мои ssd-шечки

--- TLP 1.5.0 --------------------------------------------

+++ Disks
Devices = sda sdb sdc

/dev/sda:
  Type       = SATA
  Disk ID    = ata-Samsung_SSD_860_EVO_500GB_S3Z3NB0M605776K
  Model      = Samsung SSD 860 EVO 500GB               
  Firmware   = RVT03B6Q
  APM Level  = none/disabled
  Status     = active/idle
  TRIM       = supported
  Host       = host0
  Scheduler  = none [mq-deadline] kyber bfq (multi queue)

  Runtime PM:
    /sys/block/sda/device/power/control = on, autosuspend_delay_ms = -1

  SMART info:
      5 Reallocated_Sector_Ct     =        0 
      9 Power_On_Hours            =    33592 [h]
     12 Power_Cycle_Count         =      111 
    177 Wear_Leveling_Count       =       98 [%]
    179 Used_Rsvd_Blk_Cnt_Tot     =        0 
    190 Airflow_Temperature_Cel   =       39 [°C]
    241 Total_LBAs_Written        =   17.680 [TB]

/dev/sdb:
  Type       = SATA
  Disk ID    = ata-TEAM_T253X6002T_TPBF2009140020500353
  Model      = TEAM T253X6002T                         
  Firmware   = T0805A0 
  APM Level  = none/disabled
  Status     = active/idle
  TRIM       = supported
  Host       = host1
  Scheduler  = none [mq-deadline] kyber bfq (multi queue)

  Runtime PM:
    /sys/block/sdb/device/power/control = on, autosuspend_delay_ms = -1

  SMART info:
      5 Reallocated_Sector_Ct     =        0 
      9 Power_On_Hours            =    10485 [h]
     12 Power_Cycle_Count         =       24 
    177 Wear_Leveling_Count       =      100 [%]
    178 Used_Rsvd_Blk_Cnt_Chip    =        0 
    194 Temperature_Celsius       =        0    [°C]
    232 Available_Reservd_Space   =      100 [%]
    241 Total_LBAs_Written        =    0.000 [TB]

/dev/sdc:
  Type       = SATA
  Disk ID    = ata-INTEL_SSDSA2CW080G3_CVPR12250026080BGN
  Model      = INTEL SSDSA2CW080G3                     
  Firmware   = 4PC10362
  APM Level  = none/disabled
  Status     = active/idle
  TRIM       = supported
  Host       = host5
  Scheduler  = none [mq-deadline] kyber bfq (multi queue)

  Runtime PM:
    /sys/block/sdc/device/power/control = on, autosuspend_delay_ms = -1

  SMART info:
      4 Start_Stop_Count          =        0 
      5 Reallocated_Sector_Ct     =        0 
      9 Power_On_Hours            =    52479 [h]
     12 Power_Cycle_Count         =     1761 
    225 Host_Writes_32MiB         =   34.079 [TB]
    232 Available_Reservd_Space   =      100 [%]
    233 Media_Wearout_Indicator   =       90 [%]
    241 Host_Writes_32MiB         =   34.079 [TB]

Самому старому уже 6 лет почти, износ 10%.

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

Ясно. Ни пруфов, ничего. Я так и думал. В гугле одна пространная инфа «посмотрите данные S.M.A.R.T». Серьезно? :) Кто вам рассказал о вшитом n-количестве записей в ячейку? Кто поделился промышленным секретом? Дядя Петя из соседнего двора? Ну так бы и сказали тогда.

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

Кстати да, испытания SSD показали, что производители, как правило, занижают ресурс памяти в гарантии, порой на порядок.

https://3dnews.ru/938764/resursnie-ispitaniya-ssd-obnovlyaemiy-material/page-3.html#%D0%97%D0%B0%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5

alex1101
()
Последнее исправление: alex1101 (всего исправлений: 1)
Ответ на: комментарий от Gonzo

Кто вам рассказал о вшитом n-количестве записей в ячейку?

Гугл.

В гугле одна пространная инфа «посмотрите данные S.M.A.R.T».

Видимо у нас разные гуглы. По вашим запросам выдает сссылки на вкудахнете и т.п. «фотки котиков», а у меня в первых ссылках на технологию.

anc ★★★★★
()

Если есть частые обращения к одним и тем же данным, поможет кэш ФС в RAM (достаточно добавить планку или убрать жручие процессы из системы), и, возможно, кэш на SSD (средствами bcache, zfs и т.д.)

Если обращения происходят рандомно ко всему объему без четких паттернов, то поможет только переход с HDD на более быстрый носитель

UPD: По части кэширования в RAM см. также https://www.elastic.co/guide/en/elasticsearch/reference/current/preload-data-to-file-system-cache.html - кэш можно заполнить заранее при старте

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 1)
Ответ на: комментарий от annulen

Если обращения происходят рандомно ко всему объему без четких паттернов, то поможет только переход с HDD на более быстрый носитель

Ну и частично может помочь отказ от использования файловой системы и правильный выбор и настройка СУБД - 130 миллионов записей и 150 гб текста вряд ли просто в текстовых файликах лежат :)

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

Ну и частично может помочь отказ от использования файловой системы

Отказ от ФС == чтение данных в обход page cache == тормоза и/или нерациональное использование оперативной памяти

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

Отказ от ФС == чтение данных в обход page cache == тормоза и/или нерациональное использование оперативной памяти

А вы не слышали о том, что у всех СУБД-шек имеется свой собственный специализированный кэш?) И что такие СУБД-шки, как Oracle и MySQL, могут работать просто с raw-разделами диска - естественно, используя свой внутренний формат хранения данных?

Так что, отказ от ФС с выбором соответствующей СУБДшки - это устранение избыточных операций ввода-вывода, связанных с обслуживанием собственно ФС, ну и освобождение ресурсов оперативной памяти для специализированного кэша самой СУБДШ-ки.

Учите мат-часть.

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

А вы не слышали о том, что у всех СУБД-шек имеется свой собственный специализированный кэш?

У Постгреса нет, и это правильно. Нефиг изобретать велосипеды вместо встроенных средств ОС

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 1)
Ответ на: комментарий от annulen

У Постгреса нет, и это правильно. Нефиг изобретать велосипеды вместо встроенных средств ОС

У Постгресса тоже есть свой кэш - просто Постгресс не умеет в raw-девайсы. Это не относится к понятию «правильно» - это относится к «было лень или слабо такое реализовать» )) Ну и админить такую конфигурацию сложнее и требует наличия грамотных DBA.

Работа напрямую с raw-девайсами - это отнюдь не «велосипеды», а суровая необходимость при работе с большими объемами данных, где требуется выжать из железа по максимуму, тем более, при использовании HDD. Ну и нахрена еще файловый кэш, когда уже есть свой?

vinvlad ★★
()
Последнее исправление: vinvlad (всего исправлений: 2)