The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Раздел полезных советов: Оптимизация использования SSD-накоп..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Оптимизация использования SSD-накоп..."  +/
Сообщение от auto_tips on 31-Авг-12, 17:12 
Ниже собраны рекомендации по оптимизации работы SSD-накопителя во FreeBSD 9.0, которые удалось найти в Сети.

Процесс установки и оптимизации под 4k блоки со сдвигом кратный 8, описывать не буду так как FreeBSD 9.0 cам все это делает (если установка выполнялась в автоматическом режиме).

После установки необходимо включить поддержку TRIM, для этого следует выполнить (диск должен быть отмонтирован  - загрузись с LiveCD):

   tunefs -t enable /dev/adaxxx

Отключение журналирования (может быть чревато более длительным временем проверки целостности ФС, если некорректно завершить работу, нажать reset, или если свет отключат  - пользуйтесь бесперебойником):

   tunefs -J disable /dev/adaxxx
   tunefs -n disable /dev/adaxxx
   tunefs -j disable /dev/adaxxx

Посмотреть состояние флагов раздела можно командой:

   tunefs -p /dev/adaxxx

Отключение лишних обновлений метаданных (noatime) и использование tmpfs для временных разделов и логов. В /etc/fstab:

   /dev/adaxxx        /        ufs    rw,noatime    1    1
   tmpfs            /tmp        tmpfs    rw        0    0
   tmpfs            /var/run    tmpfs    rw        0    0
   tmpfs            /var/spool    tmpfs    rw        0    0
   tmpfs            /var/log    tmpfs    rw        0    0

Перед добавлением убедитесь, что /var/spool, /var/log и /var/run  не содержит того, что может потребоваться между перезагрузками.

В /etc/rc.conf:

   tmpmfs="YES"
   tmpsize="20m"
   tmpmfs_flags="-S"
   varmfs="YES"
   varsize="32m"
   varmfs_flags="-S"
   populate_var="YES"

Размер  виртуальной файловой системы (tmpfs) писать в соответствии с свободным ОЗУ (в нашем примере, 20 мегабайт для /tmp и 32 мегабайт для /var).

URL:
Обсуждается: https://www.opennet.ru/tips/info/2712.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  –1 +/
Сообщение от unscrubber on 31-Авг-12, 17:12 
из личного опыта: самая важная оптимизация в использовании ssd - это ro (read-only) монтирование в fstab, а при воникновении необходимости внесения изменений - mount -w / ...после изменений mount -r /
Если надо чтобы писались данные кудато еще - подмонтируйте по сети нужные папки или с классического HDD.
6 лет freebsd на disk-on-chip flash-ata - полет нормальный.
ну а tmpfs varmfs в rc.conf это само собой... единственное bind демона надо рестартовать чтобы он воссоздал нужные ему каталоги в /var/db после того как рамдиски созданы будут (я в /usr/loca/etc/rc.d скриптик положил)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

61. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Фкуку on 07-Сен-12, 09:31 
>> это ro (read-only) монтирование...

Особливо на выделенном SQL сервере?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  –1 +/
Сообщение от Жорж on 31-Авг-12, 18:42 
Я вот думаю - есть ли смысл в этих SSD? Раз с ними такой геморрой надо плясать в обмен на скорость чтения (рекомендуется писать на них как можно меньше) - сильно ли оно выигрывает по сравнению с hdd?
На роутерах и тп, где не нужен винт - используем флешки в кач-ве носителя с ОС, на файловых серверах, базах данных и прочем где нужные винты - используем HDD, потому как надо писать\читать активно.
А какая ниша у SSD?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от миша (??) on 31-Авг-12, 21:46 
Да нет с ними никакого гемороя кроме придуманого, главное ТРИМ включить и нормально.
Пашут как обычные диски, только быстрее.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

33. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от nagual email(ok) on 04-Сен-12, 11:19 
> Да нет с ними никакого гемороя кроме придуманого, главное ТРИМ включить и
> нормально.
> Пашут как обычные диски, только быстрее.

Главное ценного на них ничего не хранить ...

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

70. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Максим (??) on 22-Сен-12, 00:52 
Вы правда не видели накрывшихся обычных дисков? Завидую. Резервные копии в любом случае не повредят...
Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

71. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Ivan (??) on 10-Окт-12, 14:35 
Ну, как сказать: http://www.thg.ru/storage/chto_nadezhnee_ssd_ili_hdd/print.h...
Если головы нет, то лучше ничего ценного и не иметь. А если она присутствует, то ssd можно пользоваться уверенно.
Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

8. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Anonplus on 01-Сен-12, 15:51 
Да а чего тут думать, посмотрите в интернетах тесты, разница с хдд ощутимая. На бытовом уровне - ОС начинает грузиться в разы быстрее. Ну и работать тоже, отзывчивость системы неплохая. У меня дома два компьютера, когда пересаживаюсь за тот, что без ссд - начинает раздражать его медлительность. К хорошему быстро привыкаешь.

>> А какая ниша у SSD?

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

60. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Анонище on 06-Сен-12, 21:01 
Главное не юзать MLC SSD в продакшене. И тогда можно будет активно читать/писать.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

66. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от sdaf on 11-Сен-12, 15:38 
Они и те и другие дохнут.
Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

3. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +1 +/
Сообщение от Аноним12 on 31-Авг-12, 18:50 
tmpfs            /var/log
Если это сделать, какой смысл в логах тогда?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от kurokaze (ok) on 03-Сен-12, 07:31 
Человек просто не осилил написать скрипт который бы при старте системы копировал бы логи в память, и syslog работал бы с ними там, а при щатдауне - чтобы копировалось обратно.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

32. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +1 +/
Сообщение от nagual email(ok) on 04-Сен-12, 11:18 
> Человек просто не осилил написать скрипт который бы при старте системы копировал
> бы логи в память, и syslog работал бы с ними там,
> а при щатдауне - чтобы копировалось обратно.

И потом в таких логах нет нихера ...

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

51. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Аноним12 on 05-Сен-12, 15:10 
ЛОги на то и нужны что бы они были, когда шатдаун происходит внезапно
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

5. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от deadless (ok) on 31-Авг-12, 23:11 
а если использовать zfs?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +1 +/
Сообщение от iZEN (ok) on 01-Сен-12, 12:59 
Для ZFS TRIM не важна, так как в ZFS можно сделать настройку размера базового блока под размер сектора SSD (512k). И тогда не будет лишних очищений и перезаписываний страниц SSD.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

10. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от pavlinux (ok) on 02-Сен-12, 04:31 
> под размер сектора SSD (512k).

У SSD нет секторов, головок и даже цилиндров :)

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

16. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от terr0rist (ok) on 02-Сен-12, 17:51 
>> под размер сектора SSD (512k).
> У SSD нет секторов, головок и даже цилиндров :)

Да вообще их и у винтов нет. Уже лет дцать как LBA. К слову, геометрически сектор -
это часть круга (!), ограниченная дугой и двумя радиусами. Так что сектор для ХДД никогда не был математически верным термином.
Кому надо, те понимают, что "сектор" SSD - это блок. :)

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

18. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  –1 +/
Сообщение от pavlinux (ok) on 02-Сен-12, 18:36 
> Кому надо, те понимают, что "сектор" SSD - это блок. :)

Блок был одним из немногих деятелей искусства Петрограда,
кто не просто принял советскую власть, но согласился
работать на её пользу. Власть широко начала использовать
имя поэта в своих целях.  Ужоснах =-о

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

12. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от ананим on 02-Сен-12, 13:00 
брехня же
http://ru.wikipedia.org/wiki/TRIM
>TRIM — команда интерфейса ATA, позволяющая операционной системе уведомить твердотельный накопитель о том, какие блоки данных больше не используются и могут быть использованы накопителем для подготовки к записи.

а правда в том, что (см. там же):
>Linux 2.6.33     Поддерживается с февраля 2010[17]
>OpenSolaris     Поддерживается с июля 2010[18]
>FreeBSD 8.3 & 9.0     Поддерживается с UFS[19], не поддерживается с ZFS[20].

и ещё немного правды
https://forums.oracle.com/forums/thread.jspa?threadID=214362...
>Re: SSD trim support and Oracle Solaris Express 11
>Posted: 25.11.2011 5:14
>Hello,
>do you know whether 'SSD trim' is supported and used on the final Solaris 11/ZFS build?
>Thanks
>Posted: 15.01.2012 20:57
>Hi Community,
>I opened an SR to ask Oracle about this. The answer: CR 6913905 covers this request and is integrated into Solaris 11 SRU 5, planned for the end of March 2012.
>Hope that helps

вот и всё. для сравнение в другой COW-fs:
https://btrfs.wiki.kernel.org/index.php/Mount_options
>ssd
>Turn on some of the SSD optimized behaviour within btrfs. This is enabled automatically by checking /sys/block/sdX/queue/rotational to be zero. This does not enables discard/TRIM !

.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

15. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от terr0rist (ok) on 02-Сен-12, 17:47 
Таки в чём iZEN не прав? В том, что блок SSD "сектором" обозвал?
Если SSD-блок равен блоку ФС, то TRIM не требуется, тк он нужен только для отметки о неиспользуемости блока SSD. Что, логично, бесполезно, если блок SSD равен блоку ФС.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

20. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  –1 +/
Сообщение от ананим on 02-Сен-12, 21:08 
для дЭбилов даю ещё раз ссылку https://www.opennet.ru/openforum/vsluhforumID3/86249.html#12
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

62. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +1 +/
Сообщение от terr0rist (ok) on 08-Сен-12, 01:41 
> для дЭбилов даю ещё раз ссылку https://www.opennet.ru/openforum/vsluhforumID3/86249.html#12

сам-то читал по этой ссылке?
Цитата
"TRIM — команда интерфейса ATA, позволяющая операционной системе уведомить твердотельный накопитель о том, какие блоки данных больше не используются и могут быть использованы накопителем для подготовки к записи."
"блоки (обычно 128 страниц или 512 Кбайт суммарно)"
"В SSD накопителях операция записи может быть проделана только для страниц, однако из-за аппаратных ограничений команда удаления всегда выполняется на весь блок"

вывод сделать за тебя или ещё раз мой пост перечитаешь? ананим такой ананим

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

65. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от абыр email on 10-Сен-12, 11:11 
Печальный вывод состоит в том что вы читать не умеете.
Попробуйте еще раз.
Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

27. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от iZEN (ok) on 03-Сен-12, 16:32 
> Если SSD-блок равен блоку ФС, то TRIM не требуется, тк он нужен
> только для отметки о неиспользуемости блока SSD. Что, логично, бесполезно, если
> блок SSD равен блоку ФС.

В SSD операции перезаписи происходят только с целым блоком (512k). TRIM отмечает СТРАНИЦЫ (4k), входящие в блок, как неиспользуемые и готовые к очистке. При очистке неиспользуемых страниц перезаписывается целый блок, который их содержит. Если блок SSD по размеру совпадает с блоком ФС, то TRIM — лишняя операция, так как ФС и так его перезапишет целиком. А когда размер блока ФС меньше размера блока SSD, то команда TRIM необходима для подготовки свободного пространства для размещения блоков ФС внутри блока SSD — без этого количество свободных блоков SSD при каждой записи данных будет уменьшаться — что мы и наблюдаем в реальности, когда классическая линуксовая ФС не поддерживает TRIM.


Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

28. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от ананим on 03-Сен-12, 22:45 
>TRIM отмечает СТРАНИЦЫ (4k), входящие в блок, как неиспользуемые и готовые к очистке.

TRIM ничего не отмечает.
TRIM - это команда, посылаемая (кстати АТА/САТА и этк. в SCSI/SAS/FC не иеет смысла) ОС системе ввода-вывода, что "де эти блоки грязные".
А поскольку АТА - тупой бай дезиггн, то бывало что всё помечалось как удалённое.
и да, всё это происходит до сброса кэша на диск.

в любом случае от размера блока не зависит. хоть 512, хоть 4к. (просто выдаст что очищено 4, а не 1)

зыж
когда сани говорили, что отлично работают с ссд, то не врали.
НО! эти ссд не те что в магазине продаются, а сас по 4-е нуля килобаксов минимум.
ну а с АТА см. выше привёл.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

63. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от terr0rist (ok) on 08-Сен-12, 01:42 
>[оверквотинг удален]
> В SSD операции перезаписи происходят только с целым блоком (512k). TRIM отмечает
> СТРАНИЦЫ (4k), входящие в блок, как неиспользуемые и готовые к очистке.
> При очистке неиспользуемых страниц перезаписывается целый блок, который их содержит. Если
> блок SSD по размеру совпадает с блоком ФС, то TRIM —
> лишняя операция, так как ФС и так его перезапишет целиком. А
> когда размер блока ФС меньше размера блока SSD, то команда TRIM
> необходима для подготовки свободного пространства для размещения блоков ФС внутри блока
> SSD — без этого количество свободных блоков SSD при каждой записи
> данных будет уменьшаться — что мы и наблюдаем в реальности, когда
> классическая линуксовая ФС не поддерживает TRIM.

я об этом и сказал.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

24. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от kurokaze (ok) on 03-Сен-12, 07:36 
> Для ZFS TRIM не важна, так как в ZFS можно сделать настройку
> размера базового блока под размер сектора SSD (512k). И тогда не
> будет лишних очищений и перезаписываний страниц SSD.

Лол! Ты даже не знаешь зачем нужен TRIM

In computing, a TRIM command allows an operating system to inform a solid-state drive (SSD) which blocks of data are no longer considered in use and can be wiped internally.

Я конечно понимаю что дело в том что:
Operating system support
Linux-kernel: 2.6.28 - 25 December 2008
FreeBSD: 8.1 - July 2010

Но тщательнее надо быть, тщательнее (с)

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

43. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от nagual email(ok) on 04-Сен-12, 17:31 
> Для ZFS TRIM не важна, так как в ZFS можно сделать настройку
> размера базового блока под размер сектора SSD (512k). И тогда не
> будет лишних очищений и перезаписываний страниц SSD.

Для ZFS TRIM не важна потому что учитывая стстистику отказов SSD ниодин здравомыслящий админ не станет хранить на SSD что то кроме кешируемых данных, а потому на SSD ZFS как в бане лыжи там и UFS сойдет и даже без +S +J ...

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

49. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Andrew Kolchoogin on 05-Сен-12, 01:55 
Ты перепутамши.

По умолчанию размер блока файловой системы влияет на поведение только файловой системы. Но она может вести себя "более лучше" (C) Света из Иваново, если знает, каков размер блока underlying direct access storage device (DASD далее для краткости).

Размер блока HDD равен 512 байтам. Лет тридцать назад, во времена MFM, размер блока HDD был равен размеру одного физического сектора -- теперь это, конечно, не так, ибо RLL'и и прочие методы оптимизации свели понятие сектора на "нет", но для магнитных накопителей это не так уж и важно.

А вот с SSD засада -- во-первых, они могут перезаписывать данные только в чистые блоки, которые для NAND равны 4К. Соответственно, для неухудшения параметров дисковой подсистемы был придуман костыль в виде TRIM, а позже -- поддержка операционками DASD'ов с размером в 4K.

Но это не вся засада. Некоторые NAND не умеют даже поблочной перезаписи -- только постраничную, а она, как известно, 512K размером. И вот тут уже всё плохо -- насколько мне известно, современных операционных систем, поддерживающих DASD'ы с блоком в полмегабайта, не существует -- то есть, либо TRIM, либо специальный тюнинг ZFS -- нужно сделать так, чтобы ZPool начинался на границе 512K (как частный случай -- занимал весь SSD), и размер его блока был тоже 512K, тогда операции на таком ZPool'е с эффективностью будут соответствовать TRIM'у.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

50. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от nagual email(ok) on 05-Сен-12, 11:06 
>[оверквотинг удален]
> параметров дисковой подсистемы был придуман костыль в виде TRIM, а позже
> -- поддержка операционками DASD'ов с размером в 4K.
> Но это не вся засада. Некоторые NAND не умеют даже поблочной перезаписи
> -- только постраничную, а она, как известно, 512K размером. И вот
> тут уже всё плохо -- насколько мне известно, современных операционных систем,
> поддерживающих DASD'ы с блоком в полмегабайта, не существует -- то есть,
> либо TRIM, либо специальный тюнинг ZFS -- нужно сделать так, чтобы
> ZPool начинался на границе 512K (как частный случай -- занимал весь
> SSD), и размер его блока был тоже 512K, тогда операции на
> таком ZPool'е с эффективностью будут соответствовать TRIM'у.

А есть примеры?

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

6. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от ALD email on 01-Сен-12, 12:54 
Давно уже перешел на ZFS + SSD
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от ixes email on 02-Сен-12, 00:01 
Ну шо вы "маслом по маслу"?
Или в fstab нужно вносить настройки, или в rc.conf, а то радиатор на проце поплавится, ага!
("челове-е-е-к", то есть это, модератор отредактируйте п-пажалуста)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +1 +/
Сообщение от o on 02-Сен-12, 11:34 
Ниша у них под всякие базы данных и свалки статики для нагруженых или относительно нагруженых проектов. Типа если ваш корпоративный сайтик с прайсом вдруг стал популярен, как сделать так чтобы ничего не переписывая, сделать чтобы он работал как раньше и не падал. Берете и переносите его на ссд и живете спокойно еще некоторое время.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  –2 +/
Сообщение от ананим on 02-Сен-12, 15:29 
У ссд?
Ниша у них - ноуты.
Меньше вес, дольше батарейка.
Субд - это райды (если ещё можно так назвать девайс с парой ксеонов на борту) и штук 30 винтов FC.
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

34. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от nagual email(ok) on 04-Сен-12, 12:30 
> У ссд?
> Ниша у них - ноуты.
> Меньше вес, дольше батарейка.
> Субд - это райды (если ещё можно так назвать девайс с парой
> ксеонов на борту) и штук 30 винтов FC.

SSD вполне годится под кеш горячего контента, главое чтоб он влез и небыло ротации ...

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

39. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от ананим on 04-Сен-12, 14:40 
под кэш и обычная память годится, а ссд в этом случае - полумеры.
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

40. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +1 +/
Сообщение от nagual email(ok) on 04-Сен-12, 16:58 
> под кэш и обычная память годится, а ссд в этом случае -
> полумеры.

Обычная память даже лучше, но когда нужно терабайт за разумные деньги ...

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

46. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от ананим on 04-Сен-12, 19:21 
терабайт именно для кэша? да ну нафиг.
пусть с этим тотже sga оракловый (в ОЗУ) сам разбирается. чекпоинт по отношению к транзакции асинхронный, да и коммит тоже ( http://www.orafaq.com/node/93 ), а для одного чтения держать такой кеш невыгодно всё-равно (на его обслуживание не меньше ресурсов потеряете, а то и больше)
Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

47. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +2 +/
Сообщение от nagual email(ok) on 04-Сен-12, 20:51 
> терабайт именно для кэша? да ну нафиг.
> пусть с этим тотже sga оракловый (в ОЗУ) сам разбирается. чекпоинт по
> отношению к транзакции асинхронный, да и коммит тоже ( http://www.orafaq.com/node/93 ),
> а для одного чтения держать такой кеш невыгодно всё-равно (на его
> обслуживание не меньше ресурсов потеряете, а то и больше)

Горячий статический контент для nginx или по вашему видеотубы как должны работать ?

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

48. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от angra (ok) on 05-Сен-12, 00:37 
Не мечите бисер, не поймут-c, провинция.
Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

54. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от ананим on 06-Сен-12, 06:56 
всё с тобой ясно. :D
Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

53. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от ананим on 06-Сен-12, 06:52 
про nginx разговора не было, был разговор про субд.
опять же - ну киньте мне ссыль у кого именно nginx и именно с терабайтными ссд.
Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

55. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от nagual email(ok) on 06-Сен-12, 09:26 
> про nginx разговора не было, был разговор про субд.
> опять же - ну киньте мне ссыль у кого именно nginx и
> именно с терабайтными ссд.

http://www.lexa.ru/nginx-ru/msg39257.html

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

25. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от kurokaze (ok) on 03-Сен-12, 07:38 
> Ниша у них под всякие базы данных и свалки статики для нагруженых
> или относительно нагруженых проектов. Типа если ваш корпоративный сайтик с прайсом
> вдруг стал популярен, как сделать так чтобы ничего не переписывая, сделать
> чтобы он работал как раньше и не падал. Берете и переносите
> его на ссд и живете спокойно еще некоторое время.

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


Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Аноним (??) on 02-Сен-12, 13:44 
А я гонял недавно сравнение HDD с интерфейсом SATAIII и SSD - разницы почти не заметил. Возможно, если SSD в PCIEx1 вставить, то скорость сразу ощутится, а так - никакого особого выигрыша...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от terr0rist (ok) on 02-Сен-12, 18:07 
В каких приложениях и на каких ФС?
Вообще говоря, утверждения о заметной разнице в скорости загрузки ОС (например) мне  кажутся сомнительными. Так как на моём ноуте (с винтом) до полминуты занимает процесс определения всяких девайсов, а сервисы загружаются за несколько секунд (что на фряхе, что на линуксах).
Какие-нибудь кеды да, возможно, будут чуть побыстрее загружаться от ССД, хотя есть ощущение, что они тормозятся специально каким-то внутренним таймером :)
Насчёт приложений, чисто логически, могут выиграть только многопользовательские, например активно использующие БД (и то, в режиме случайного чтения) или веб-порталы, т.к. скорость чтения современных винтов более чем достаточна для задач одного пользователя.
А синтетические тесты, как известно, всегда можно подогнать под желаемый результат.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

22. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от ixes email on 03-Сен-12, 00:10 
ССД предназначено для приложений работающих именно с большими данными (файлами): САПР, 3Д-разработчики, мультимедиа-конверторы, архиваторы. А вообще если вы хотите реальной скорости работы с винтом и неубиваемые ячейки памяти, копайте в сторону RAMfs и TMPfs, во где мясо. На i7-3770k 32gb (ram->ramfs) 18-гигабайтный BR-фильм конвертировался в DVD-формат вот-так: бзи-и-к (читать быстро!)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

26. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от kurokaze (ok) on 03-Сен-12, 07:43 
> RAMfs и TMPfs, во где мясо.

Проверял - смысла нет. Кеширующий механизм в линуксе настолько хорош, что при сборке qt я не заметил разницы между сборкой в памяти и сборкой с использованием диска. Разница была менее секунды.

> На i7-3770k 32gb (ram->ramfs) 18-гигабайтный
> BR-фильм конвертировался в DVD-формат вот-так: бзи-и-к (читать быстро!)

DVD формат в наше время? Фуу. Небось еще и в один проход жал

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

30. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Arti (??) on 04-Сен-12, 02:58 
ты современный накопитель таким образом убить собираешся? флаг в руки, барабан на шею.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

31. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +1 +/
Сообщение от evildim on 04-Сен-12, 07:56 
> ССД предназначено для приложений работающих именно с большими данными (файлами): САПР,
> 3Д-разработчики, мультимедиа-конверторы, архиваторы.

Вообще-то SSD рекомендуется использовать для приложений, которые требуют больших IOPS-ов и малого responce time. А "с большими данными" SSD не используют просто в силу слишком большой цены. Интересубщиеся могут заглянуть в прайсы и сравнить цену для SATA, SAS и SSD дисков аналогичной ёмкости.

Почитайте что-ли хотя бы для общего развития рекомендации от производителей систем хранения данных: EMC, Hitatchi, NetApp. У них на эту тему весьма подробно рассказано про FAST Cache (ssd используется в качестве кэша для часто читаемых данных), FAST VP (наиболее активно используемые данные перемещаются на более быстрые диски), и прочие подобные технологии.

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

29. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Arti (??) on 04-Сен-12, 02:19 
какой-то бред ты ходь бы написал как геомовскую делету заюзать, а это хлам. SSD без трима, хотя на системный диск смонтирванный в RO поканает.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

35. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от nagual email(ok) on 04-Сен-12, 12:35 
> какой-то бред ты ходь бы написал как геомовскую делету заюзать, а это
> хлам. SSD без трима, хотя на системный диск смонтирванный в RO
> поканает.

Если рассматривать кеширование горячих данных под веб то 1 SSD диск заменит 16 SATA по скорости но не по объёму.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

36. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Arti (??) on 04-Сен-12, 13:44 
т.е.? блин год назвад подруги впери оди 320 винт. нна считал тоже год рабо тоже ссд ну там мелкий, на домашнем компе два по 200. не я понимаю что не 16 теробайтных, но всётаки далеко не всегда нужна тихая файлопомойка.
Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

37. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Arti (??) on 04-Сен-12, 13:53 
считал = считалка
в ноуте для работы тоже год там 160 - так себе вин по объёму, но ноут роняли уже несчетное количество раз - и ему пофиг, и прикольно когда залезаешь на чердак проверить что-то - фря загружается почти мгновенно.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

38. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Arti (??) on 04-Сен-12, 14:21 
надаче както ноут с холодилника грохнули - думал ваще ралетится - но нет  не разлетелся - и ему это подение по барабану - даже не перегрузился.

ваще если есть желание надо фак по триму в бсд написать - по-моему боле актуально - тмпфс - часто юзаю и на обычных винтах - там как раз что-то бырое положить. т.е. к ссд это не всегда имеет отношение.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

41. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Arti (??) on 04-Сен-12, 17:03 
здесь кста круче - всего-то надо ключ подсунуть.
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

42. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Arti (??) on 04-Сен-12, 17:04 
> здесь кста круче - всего-то надо ключ подсунуть.

http://forums.freebsd.org/showthread.php?t=28004

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

44. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Arti (??) on 04-Сен-12, 18:11 
получается как-то так:
protocol              ATA/ATAPI-8 SATA 2.x
device model          OCZ-VERTEX2 3.5
firmware revision     1.24
serial number         OCZ-141G45617E8EAAE5
WWN                   5e83a97f49d4ff28
cylinders             16383
heads                 16
sectors/track         63
sector size           logical 512, physical 512, offset 0
LBA supported         268435455 sectors
LBA48 supported       468862128 sectors
PIO supported         PIO4
DMA supported         WDMA2 UDMA6
media RPM             non-rotating

Feature                      Support  Enabled   Value           Vendor
read ahead                     yes      yes
write cache                    yes      yes
flush cache                    yes      yes
overlap                        no
Tagged Command Queuing (TCQ)   no       no
Native Command Queuing (NCQ)   yes              32 tags
SMART                          yes      yes
microcode download             yes      yes
security                       yes      no
power management               yes      yes
advanced power management      no       no
automatic acoustic management  no       no
media status notification      no       no
power-up in Standby            no       no
write-read-verify              no       no
unload                         yes      yes
free-fall                      no       no
data set management (TRIM)     yes
root: tunefs -p /home
tunefs: POSIX.1e ACLs: (-a)                                disabled
tunefs: NFSv4 ACLs: (-N)                                   disabled
tunefs: MAC multilabel: (-l)                               disabled
tunefs: soft updates: (-n)                                 enabled
tunefs: soft update journaling: (-j)                       enabled
tunefs: gjournal: (-J)                                     disabled
tunefs: trim: (-t)                                         enabled
tunefs: maximum blocks per file in a cylinder group: (-e)  2048
tunefs: average file size: (-f)                            16384
tunefs: average number of files in a directory: (-s)       64
tunefs: minimum percentage of free space: (-m)             8%
tunefs: optimization preference: (-o)                      time
tunefs: volume label: (-L)                                 hsdata

root: dd if=/dev/random of=ttt.rnd bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 12.652015 secs (84867258 bytes/sec)
root:

понятно что dd - не бенч, но порядок цен.

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

45. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Arti (??) on 04-Сен-12, 18:27 
т.е статья сноводится до man tunefs
Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

69. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Аноним (??) on 17-Сен-12, 03:08 
"Процесс установки и оптимизации под 4k блоки со сдвигом кратный 8, описывать не
буду так как FreeBSD 9.0 cам все это делает (если установка выполнялась в
автоматическом режиме)" - и зря. интересует настройка с "нуля", руками, а не пересказ man tunefs и очень сомнительные изъяснения о tmpfs на критически важных разделах.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

72. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Аноним (??) on 06-Ноя-12, 03:19 
Афтар лох пиши исчо
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

73. "Раздел полезных советов: Оптимизация использования SSD-накоп..."  +/
Сообщение от nagual email(ok) on 06-Ноя-12, 03:29 
> со сдвигом кратный 8

Это как ?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

74. "Оптимизация использования SSD-накопителя во FreeBSD 9.0 "  +/
Сообщение от Винер email on 19-Авг-14, 12:07 
Данный метод применителен к freebsd 10?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру