Причём, как старые, так и свежесоздаваемая (например, Гилёв-тест тот же).

Файловые стали летать, как на самолёте.

Переносил созданием еще одного RAID-массива, остановкой SQL, Сервера 1С:Предприятия, копированием и переназначением букв дисков.

Затем ребут, проверка и на всякий случай еще раз ребут.

Утром бухи пожаловались, что несколько баз начало жутко тормозить, а остальные наоборот - залетали.

Летать стали файловые, тормозить SQL-ные

Тест Гилёва подтвердил: SQL-ная версия - 10 баллов, файловая - 40 баллов.

Вечером ребутну, конечно, сервак, но хотелось бы чьего-то опыта - что могло произойти?

Выгрузить-загрузить базу не предлагать - база теста Гилёва создавалась уже после замены

(0) а где раньше темп был у сиквела ?

глянь размещение темпдб.

Ну и традиционно - обновление статистики

(1),(2) - ничего не менялось, специально тормозил скуль и буквы дисков после копирования переназначал
(3): А к только что созданной базе это как относится?

(4) 1. Ну так где были "до" и где сейчас?
2. а загрузка  в базу - не процесс? ли просто детач-аттач?

Создал рэйд из ссд?

(5): Были на SAS-RAID-1, теперь на SSD-RAID-1, буква диска не менялась, пути те же.
(6): Да, RAID-1.

Еще раз повторю: рядом тут же, на этом же диске лежат файловые версии, они стали быстрее в 5 раз после перевода на SSD.
SQL_ные базы замедлились в 10 раз

Ну и чтобы два раза не вставать: данную процедуру проводил на других серверах именно таким образом десятки раз.

Никогда SQL после этого не начинал тормозить

(7) ещё раз
регламенты на сиквеле проведены ?

ну не знаю...
посмотри уж, чего сервер ждет... чем-нибудь типа http://catalog.mista.ru/public/16681/

Если диски SSD не корп, тогда чего ждать прироста?

(11) ставили "бытовые". с говорящим названием "адреналин".
пока от поставщика шли серверные. прирост скорости все равно был весьма ощутимым по сравнению с сас

(11): Вы читали всё, что я описывал? Про то, что такую операцию я проводил десятки раз, про то, что замедлился только SQL, причём в десяток раз и пр.

Регламенты проведу вечером полные, в (0) написал про это.

Просто заранее спросил - вдруг решение однозначно, очевидно и давно известно.
Но всё равно ответы типа (11) именно в этой теме умиляют

(13) а что на счет (10)?

(14): Сорри, только добрался. Сейчас Гилёв выдает 20, вместо 10 днём (никто не работает).

На Гилёве вот так тест показал:
XE_TIMER_EVENT    540004.0    20.5
SQLTRACE_INCREMENTAL_FLUSH_SLEEP    540000.0    20.5
REQUEST_FOR_DEADLOCK_SEARCH    540004.0    20.5
CHECKPOINT_QUEUE    471756.0    17.9
BROKER_TO_FLUSH    270567.0    10.3
SLEEP_TASK    269590.0    10.2
WRITELOG    3615.0    0.1

Завтра утром проверим, что юзеры скажут, но сегодня удивило именно замедление в 10 раз, хотя для SQL ничего не изменилось, он даже не в курсе был, что ему диск под базы подменили

Может ОФФ но похожий вопрос.
В ноуте с SSD идет можно SSD заменить на HDD (там "разъемы" одинаковые)???

(17) Одинаковые. Главное что бы по размеру подошел, SSD как правило тоньше обычных винтов. Но думаю в ноуте место сделано универсальное.

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

(18) (19) спасибо

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

(9): Регламенты проведены полностью.

(21) спасибо. все понял, не будем мешать ТСу

(22) У вас SSD в рэйде. Стало быть TRIM не работает.

Отсюда вопрос - какие SSD серверные или десктопные?
И если десктопные, то какой резерв вы оставили под запись?

(24): SSD - десктопные. Под резерв оставлено 15%.

Первым делом проверил на одиночном SSD (он там есть под Hotspare) - разницы нет никакой.

Как "не работает TRIM" объясняет, что файловые базы ускорились в 5 раз, а SQL-ные - замедлились в 10? На этом же самом сервере, на этой же самой ОС.

Или вы мои посты не читали?

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

(26): А десятки проведённых мной точно таких же операций на других серверах, в результате которых ни разу не было подобного глюка замедления как объясняются?

Microsof давненько так заявляла, что при заполнении HDD более 85% производительность резко снижается и исправляется это только переформатированием жесткого диска. Все таки каков размер tempdb?

(16) Во во. А надо было детач/аттач :)

(16) Да, кстати - проверь права на базу. Может в этом проблема.

(28): свободно 50% пространства (100 гигабайт). Tempdb - 670 мегабайт.
(29): Вот я сам только к такому варианту склоняюсь, что SQL как-то на размещение базы не только на файловом, но и на дисково-секторном уровне смотрит. Но тогда непонятен многократный успешный опыт до этого.
(30): А что может случиться с правами на базу, если SQL тот же самый и база та же самая?

(31) Ну так тебе эту процедуру и сейчас никто не мешает сделать. :)

(29) так а как без детача-аттача?
(31) да, он статистику как-то перестраивает.
попробуй хотя б перииндексироваться, чтоль..
Но что-то меня в (15) напрягает....

(33) Как то так....
(0) Переносил созданием еще одного RAID-массива, остановкой SQL, Сервера 1С:Предприятия, копированием и переназначением букв дисков.
(16) хотя для SQL ничего не изменилось, он даже не в курсе был, что ему диск под базы подменили

(33): Естественно, что как и говорил днём - вечером провёл полное обслуживание SQL базы. Скорость возросла, но я не могу проверить то, что бухи видят. Жду их прихода.
Детач-Аттач уже переиндексированной базы провёл, скорость осталась той же, но я думаю, что больше 22 по Гилёву и не достичь на такой системе старой. Вчера было 6

(31) Думается, "многократный опыт" объясняется тем, что БД попали в аналогичные сектора, т.е. изначально был пустой диск, на него положили БД, потом скопировали, опять же на пустой - профит (если как-то сместились сектора, придётся делать обслуживание БД для перестройки служебных данных).

Собираюсь проводить в будущем такую же операцию .
Можете написать какие модели дисков поставили?

(37): Да не помню я в этот раз какие - переставлял из соседнего сервера, в котором временно год назад такую операцию проводили (то есть диски относительно новые), а потом весь сервер заменили на новый.
OCZ какие-то.
Вообще из десктопных постоянно покупаю Kingston 300-ой серии. Выходов из строя пока не было, но всегда беру 3-4 штуки - два в RAID-1 и 1-2 в Hotspare

Понятно, что в "настоящих" серверах использую Intel 37xx Series, но в псевдо-серверах, когда заказчик каждую копейку считает, такие не купишь.

(38) Спасибо

(17) SSD может быть M.2 - тогда HDD поставить не получится скорее всего.

(27) Например, один из дисков не совсем исправен.

Кстати, у некоторых Кингстонов была фича - если на них много писать - быстро срабатывает ограничитель и скорость записи становится ниже чем у HDD. Типа, чтобы до гарантии не выработался ресурс диска.

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

Всем спасибо, даже тем, что не читал то, что я явно написал, чтобы избавиться от вариантов в стиле "а чего вы хотите то, SSD не серверный"

(43) погоди. а как ты копировал без детача-аттача???

(44) Чукча писатель!
:) :) :)
(0), (16)

(45) мля. угу... :-(((

(42) Какие ограничители? Какой ресурс?

SSD быстро пишет пока есть куда писать - кончились чистые блоки из резерва и скорсоть записи проседает в десятки раз.
Ибо очистка блока офигенно длительный и ресурсоемкий процесс.

(25) "Под резерв оставлено 15%" - это ни о чем не говорит, пока не известен объем SSD  и хотя бы размер скулевой базы, а еще лучше объем однократной записи SQL.

"Как "не работает TRIM" объясняет, что файловые базы ускорились в 5 раз, а SQL-ные - замедлились в 10? "  - вот так и объясняет.


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


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

(47) http://ssdendurance.com/ssd-endurance-test-report/Kingston-SSDNow-V300-60

См. про degraded state. Это именно что фича Кингстона для того, чтобы диск прожил гарантию:

"Kingston just confirmed the severe speed issues. This is a "feature" called Drive Life Protection - DLP and it will "throttle back its performance to reduce writes" in order "to protect itself to ensure the warranty period". DLP basically renders the drive useless (temporarily?). Allowing the disk to idle for 13 hours did not make the unit recover. The drive is currently left idle. I'd stay away from the Kingston SSDNow V300 for write intense environments."

+(49) Если посмотришь, то там скорость записи упала до 1 Мб/с (одного мегабайта в секунду).

для SSD дисков в биосе и винде нужно ОБЯЗАТЕЛЬНО спец настройки делать, как минимум поддержку трима включить....

почитаете.... а то угробите все нафиг....

кроме того для SSD утилиты от HDD не подходят...

(49)Нет такой фичи у кингстона.
Это какая то старая и дурацкая статейка на левом ресурсе.

Деградация при записи происходит когда диску банально некуда писать.
Нет свободных ячеек. И диск перед каждой записью должен очистить ячейки.

Например вам нужно записать данные размером 4килобайта, а писать некуда.
Происходит следующее -
1)Читается в оперативную память SSD блок из 128ячеек по 4кб каждая.
2)Стирается весь этот блок.
3)На чистый блок записывается обратно около 100-400Кб информации которую не нужно было удалять, ну и сосбтвенно ваша информация размером 4кб.

Этот процесс требует кучу процессорного времени, и кучу оперативной памяти.
А как вы думаете насколько производительный процессор стоит в SSD за 50$ и сколько оперативки DDR3 там распаяно?

(51) Каких то спецнастроек обязательных для SSD нет.
И уж угробить диск таким образом невозможно.

Максимум что произойдет это он будет работать не так быстро как хотелось.

А в биосе можно только одну настройку для SSD сделать  - включить AHCI

(52) Да, да, да. И 230 атрибута в SMART-е нету:

http://media.kingston.com/support/downloads/MKP_306_SMART_attribute.pdf

230 Drive Life Protection Status

Current state of drive operation based upon the Life Curve. Extreme conditions will require the drive to protect itself to ensure the warranty period.

Normalized Equation:
100=usage does not require protection
90=currently protected

Normalized Value Range: Best = 100 Worst = 90 (protection active)

Raw Usage: None (0x00)

When protection is not active, this value reads 100.
If the PE Cycle usage trajectory threatens to violate the Life Curve usage schedule for the block that has the minimum PE cycles left unused, protection activates to forbid such violation and this value reads 90.

(54)Это парметр SMART как вы верно заметили, и он показывает состояние защиты, когда диск уже изношен до предела.
Перед тем как рассыпаться, чтобы продлить агонию, и дослужить гарантию.
Т.е срабатывание этой защиты это повод срочно поменять диск. дабы не потерять данные.
И только.

Такого рода защита предусмотрена на всех дисках.

Увидели включение защиты - ставите новый диск, и выкидываете старый на помойку.

(55) Нет, этот атрибут показывает состояние защиты если диск изнашивается быстрее, чем заложено разработчиком, что может вызвать его износ в период гарантии. Он переключается в обоих направлениях. Если диск немного постоит без записи - защита выключится. Почитайте хотя бы описание атрибута, чтоли. Это именно фича Кингстона. Интел на том же контроллере такой защиты не имеет.

Чем СМАРТ в винде снять Кингстона порекомендуете?

*с