Добрый день, уважаемые форумчане. Имеем клиент серверную 1С. Файлы MSSQL лежать на SSD. Для увеличение производительности решили с обычного жесткого на отдельный SSD перенести кэш сервера 1С, что в srvinfo. Теперь в течение уже пару часов с бешенной скоростью идет запись и чтение в различные файлы. Прикол в том что производительность наоборот упала. Подскажите в чем ошибка, как поправить ситуацию.

Слишком много информации. Нужно еще меньше.

(1) А ты уточни какой информации тебе не хватает для твоих умозаключений. Если бы я знал на что обратить внимание в такой ситуации - вопросов не задавал бы. В чем моя логика была - есть кэш агента сервера, если перенесем службу на отдельный SSD то должно быть лучше. Единственное что не стали тащить КЭШ на 90 гигов, а решили что пускай новый сформируется лучше. Но формируется он че то прям очень долго уже.

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

(1) Решили с обычного жесткого на отдельный SSD перенести кэш сервера 1С, единственное что не стали тащить КЭШ на 90 гигов.

(3) Нам на время жизни его по большей части всё равно, так как он специально под это отдельно под эти нужды был выделен. Устанет - не сильно страшно. По поводу скорости записи - скоросто записи явно больше выдаётся чем на хардах. Нам непонятно че он там щас такое дурниной пишет без остановки. Просто у нас был уже подобный опыт на другой организации, сделали по сути тоже самое, в итоге работать стало веселее. Тут же как то не так пошло

(4) ну да, так и было. Сколько времени должно уйти на формирование КЭШа?

(5) вам надо было прежде, чем нагружать диски операциями чтения и записи, задуматься о том,
что "караван движется со скоростью равной самому медленному верблюду"

Супер-Диски только _иногда_ позволяют ускорить работу системы целом в длительном режиме. Т.е. не в момент перезагрузки операционной системы, когда все возможные и невозможные куски системы пустые и на 90% только считывается информация с загрузчика ОС, а уже после этого - все загружено, все запущено, все привязалось друг к дружке и начало движение в режиме длительной, скажем так, конвейерной обработки данных/запросов/операций/процессов

(0) Вы каталог заново создавали или копировали существующий?
Если заново - возможно, идет перестроение полнотекстового поиска. Ждите когда перестроится.

(8) >> идет перестроение полнотекстового поиска

+100500.

По всем базам идёт построение индекса ППД.
Ждите пока построиться. Время зависит от объема баз, настройки регламентов обновления и слияния индекса и интенсивности текущих изменений в данных, генерируемых работающими пользователями.

>> не стали тащить КЭШ на 90 гигов.

Странные вы люди. Вы вообще в курсе что именно содержится в папочке srvinfo? Данные полнотекстового поиска, журналы регистрации... Кэш - всего лишь самая малая и незначительная часть из того, что там находится.

(0)
Полнотекстовый индекс.
Посмотрите в регламентных заданиях.

(9) мы оценили свою ошибку)) ну тут дело даже не в этом. По монитору ресурсов такое ощущение было, что агент сервера без остановки выполнял одни и те же действия циклично, как то неадекватно себя повёл. Прикол в том что когда перенесли обратно на C - он какое то время помолотил и перестал.

(11) он нашел свои уже сформированные индексы и упокоился.

(11) >> когда перенесли обратно на C - он какое то время помолотил и перестал.

Логично. На С система нашла уже существующие данные индекса ППД, актуализировала их и успокоилась.
А на новом SSD она полностью с нуля строила индексы ППД.

При переносе данных реестра кластера серверов (папочки srvinfo) можно идти двумя путями:

Первый (копирование/перенос накопленных данных).
1. Останавливаем службы сервера.
2. копируем целиком папочку srvinfo в новое место. (кроме сеансовых данных, которые лежат в папке snccntx*).
3. перепрописываем в строке запуска службы 1С адрес папочки srvinfo
4. запускаем службу

Второй (жизнь с чистого листа).
Всё тоже самое, но пункт "2" исключаем.
Добавляем пункт 5. Войти в каждую базу монопольно и запустить вручную обновление (построение с нуля) индекса ППД.

При втором варианте надо учитывать, что данные журналов регистрации у вас останутся в старой папке. И журналы начнутся с момента запуска службы 1С.

(11) >> агент сервера без остановки выполнял одни и те же действия циклично, как то неадекватно себя повёл.

Наоборот. Он повёл себя абсолютно адекватно. В каждой базе настроен регламент по обновлению и слиянию индекса ППД. Когда индекс нормальный, этот регламент отрабатывает за секунды (нашёл только добавленную и измененную информацию и прописал её в индекс ППД). А когда индекс пустой, ВСЯ информация в базе данных становится для индекса ППД новой и нужно ВСЮ БД перелопатить для его актуализации. Соответственно при каждом запуске регламент обновления отрабатывает не секунды, а всё отведенное ему время. При стандартной настройке расписания этого регламента (обычно каждые полминуты, минуту или две минуты) получаем ежеминутный запуск обновления индекса в каждой базе (если их несколько).

(14) Спасибо большое за грамотное разъяснение. На ночь поставим построение ППД.