Вход | Регистрация
 

1C. Кэш сервера. Быстродействие

1C. Кэш сервера. Быстродействие
Я
   kostyk92
 
30.05.19 - 08:20
Добрый день, уважаемые форумчане. Имеем клиент серверную 1С. Файлы MSSQL лежать на SSD. Для увеличение производительности решили с обычного жесткого на отдельный SSD перенести кэш сервера 1С, что в srvinfo. Теперь в течение уже пару часов с бешенной скоростью идет запись и чтение в различные файлы. Прикол в том что производительность наоборот упала. Подскажите в чем ошибка, как поправить ситуацию.
 
 
   Галахад
 
1 - 30.05.19 - 08:23
Слишком много информации. Нужно еще меньше.
   kostyk92
 
2 - 30.05.19 - 08:32
(1) А ты уточни какой информации тебе не хватает для твоих умозаключений. Если бы я знал на что обратить внимание в такой ситуации - вопросов не задавал бы. В чем моя логика была - есть кэш агента сервера, если перенесем службу на отдельный SSD то должно быть лучше. Единственное что не стали тащить КЭШ на 90 гигов, а решили что пускай новый сформируется лучше. Но формируется он че то прям очень долго уже.
   Сияющий в темноте
 
3 - 30.05.19 - 08:36
таки ssd на запись не очень быстры,да и постоянная перезапись сказывается на их времени жизни.
и потом,кеш в 1с не очень разумно сделан,и файлы бездумно перезаписываются.
   zva
 
4 - 30.05.19 - 08:38
(1) Решили с обычного жесткого на отдельный SSD перенести кэш сервера 1С, единственное что не стали тащить КЭШ на 90 гигов.
   kostyk92
 
5 - 30.05.19 - 08:50
(3) Нам на время жизни его по большей части всё равно, так как он специально под это отдельно под эти нужды был выделен. Устанет - не сильно страшно. По поводу скорости записи - скоросто записи явно больше выдаётся чем на хардах. Нам непонятно че он там щас такое дурниной пишет без остановки. Просто у нас был уже подобный опыт на другой организации, сделали по сути тоже самое, в итоге работать стало веселее. Тут же как то не так пошло
   kostyk92
 
6 - 30.05.19 - 09:03
(4) ну да, так и было. Сколько времени должно уйти на формирование КЭШа?
   Фрэнки
 
7 - 30.05.19 - 09:05
(5) вам надо было прежде, чем нагружать диски операциями чтения и записи, задуматься о том,
что "караван движется со скоростью равной самому медленному верблюду"

Супер-Диски только _иногда_ позволяют ускорить работу системы целом в длительном режиме. Т.е. не в момент перезагрузки операционной системы, когда все возможные и невозможные куски системы пустые и на 90% только считывается информация с загрузчика ОС, а уже после этого - все загружено, все запущено, все привязалось друг к дружке и начало движение в режиме длительной, скажем так, конвейерной обработки данных/запросов/операций/процессов
   ptiz
 
8 - 30.05.19 - 09:17
(0) Вы каталог заново создавали или копировали существующий?
Если заново - возможно, идет перестроение полнотекстового поиска. Ждите когда перестроится.
   unregistered
 
9 - 30.05.19 - 10:19
(8) >> идет перестроение полнотекстового поиска

+100500.

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

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

Странные вы люди. Вы вообще в курсе что именно содержится в папочке srvinfo? Данные полнотекстового поиска, журналы регистрации... Кэш - всего лишь самая малая и незначительная часть из того, что там находится.
   pavig
 
10 - 30.05.19 - 10:23
(0)
Полнотекстовый индекс.
Посмотрите в регламентных заданиях.
   kostyk92
 
11 - 30.05.19 - 10:53
(9) мы оценили свою ошибку)) ну тут дело даже не в этом. По монитору ресурсов такое ощущение было, что агент сервера без остановки выполнял одни и те же действия циклично, как то неадекватно себя повёл. Прикол в том что когда перенесли обратно на C - он какое то время помолотил и перестал.
   lodger
 
12 - 30.05.19 - 10:57
(11) он нашел свои уже сформированные индексы и упокоился.
   unregistered
 
13 - 30.05.19 - 11:02
(11) >> когда перенесли обратно на C - он какое то время помолотил и перестал.

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

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

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

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

При втором варианте надо учитывать, что данные журналов регистрации у вас останутся в старой папке. И журналы начнутся с момента запуска службы 1С.
   unregistered
 
14 - 30.05.19 - 11:10
(11) >> агент сервера без остановки выполнял одни и те же действия циклично, как то неадекватно себя повёл.

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

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.