v7: Постоянные транзакции и блокировки 1SJOURN #718996

В базе работает 30 пользователей, файловая, база тупит. Что можно сделать чтоб работало быстрее, SSD например, приветствуются любые идеи

В базе работает 30 пользователей, файловая, база тупит. Что можно сделать чтоб работало быстрее, SSD например, приветствуются любые идеи

В базе работает 30 пользователей, файловая, база тупит. Что можно сделать чтоб работало быстрее, SSD например, приветствуются любые идеи

Терминал + отказ от массовой работы задним числом.

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

Конфигурация то хоть какая? Размер базы. Какие 3 самых крупных файла? Сервер какой, терминал?

работа сегодняшней датой конфигурация самописная, самый крупный файл 1200 мб - таблица с заказами, при записи этих документов тупит база

Научиться пользоваться поиском. Если сам неосилишь то пригласить специалиста. Если первые 2 варианта явно не ваш метод - запасайтесь вазелином и пользуйте метод ненаучного тыка. Бекапы при этом можно уже и не делать.

сервер 24 ядра, 32 ОЗУ, узкого места в железе не выявили

Терминал, Windows Server 2008 R2 Standart

1200 метров - скоро будет белый зверёк. По сути вопроса - режьте базу или переходите на sql (правда быстрее не станет). Работу с sql могут ускорить прямые запросы к базе, но это древнее шаманство мало кто помнит.

Да хоть тыщу ядер поставь на файл-сервер - толку не будет..

Обязательно ставьте патч Ромикса vk_TerminalSleep.. Ну и оптимизацией базы займитесь.

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

Мне кажется надо регистр закрыть :) Тут способы ускорений:

Перейти на восьмерку.

Файловая восьмерка на том же железе загнется на 5 юзверях. Дальнейшие действия?

подчистить базу вот этим

Кто-то предлагал файловую? Месье мазохист?

еще раз для "тупых" ;-) (недеюсь не обидешься) - работа задним числом в сегодняшней дате - это запросто - проведение любого дока у которого позиция не совпадает с ТА - это есть работа задним числом. независимо от даты - хоть вчера, хоть сегодня. . все массово и постоянно выполянемые проведения/операции должны исполняться в ТА. . 20 юзверей на одноядерном проце лохматой давности в файловом варианте в терминале - с транзакциями сталкивались в день эпизодически.

насколько помню для семерки для конкретного пользователя без разницы сколько ядер вообще, использоваться будет только одно. Поэтому имее смысл брать с максимальной тактовой частотой проц.

Просто топег прочитал "В базе работает 30 пользователей, файловая"

(6,7) на таком сервере 30 юзверей ПРИ ИНТЕРАКТИВНОЙ РАБОТЕ - чтобы тупило и падало в блокировки - надо очень сильно псотараться... или наоборот - нифига не стараться и писать код от балды.

И что? Это означает, что предлагать можно тоже только файловую? Что за странные ограничения?

КЦ, глянь почту

Если узкого места в железе не выявили счетчиками (т.е. SSD не очень-то и поможет), тогда можно замер производительности в отладчике например попробовать.

1200 - размер маленький, у нас 5 Гб - файловая 7.7 - самописка.

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

В любом случае восьмерка прожорливее, про "функционал" и "скорость" типовых уже молчу... И это... перейти не всегда так просто как кажется... Если рассматриваете возможность привлечения сторонних трудовых ресурсов - могу помочь, почта в личке.

>>В любом случае восьмерка прожорливее >>И это... перейти не всегда так просто как кажется... У нас соревнование, кто больше напишет банальных истин, не относящихся к обсуждаемой теме? Земля круглая. 2 + 2 = 4.

Нет, пелять, у нас "тупой и еще тупее" Вот скажи, твой совет по переходу на 8.х к чему в этой ветке?

Мой совет — это прямая рекомендация на вопрос в "Что можно сделать чтоб работало быстрее, SSD например, приветствуются любые идеи".

2+2 = 3.9999999999999999

Переход на SQL + "Гибкие блокировки"

SQL + терминал + патч Ромикса, переписать критичные места, и оторвать руки тому кто поставил это всё на 24-ядерный сервак.

SSD естественно не нужно, ибо на SQL, при включенном AWE - всё будет в кеше.

При секретном релизе патч ромикса не нужен на сколько я помню. А ставить старый скуль смысла нет, если ставить то 2008.

И получить геммор? ИМХО если софт заточен под SQL2000, то он лучше будет работать на SQL2000.

Переписать на прямых запросах

И лишится всех прелестей новой СУБД.

Отсюда вывод: 1Ской занимается админ, который в 1С нифига не соображает.

Примеры неудачные... Если уж на то пошло, снег не абсолютно белый. А земля не круглая. Она сплюснута с полюсов.

По сабжу: обратитесь к  специалисту. Для точного диагноза нужен физический доступ к базе.

В качестве мелкого увеличения быстродействия (влияет в основном на отчеты) можно сделать рам-диск и вынести на него временные файлы. Есть еще такие драйвера рам-диска, которые используют память в качестве буффера - дубрируют данные HDD на рамдиске, получается скорость рам-диска и надёжность HDD. Можно еще отключить патчем в 1С принудительный сброс буфферов на диск и включить кеширование на запись. Но всё это только в случае, если у вас хороший и правильно настроенный UPS. Если нет - вы этих советов не видели.

сомнительный вывод.

Ну у кого как, да. У кого-то и пи в военное время равно 4.

Я знал, что какой-нить педант обязательно так скажет :))

можете обосновать свое мнение?

"Но всё это только в случае, если у вас хороший и правильно настроенный UPS..." ...А также хорошая и правильно настроенная ОС, хороший и правильно настроенный кондиционер в серверной и хорошая база, которая позволяет потерять часть вбитых данных. Все-таки рам-диск -- очень рискованная вещь, я бы побоялся в продакшне использовать. На самом деле SLQ + "гибкие блокировки" помогут избежать долгих ожиданий на записи. Если искать альтернативы -- то только ускорение физической записи (то есть, да, SSD или домоклов меч рам-диска). Но это все видится как экстенсивное решение проблемы

твое ИМХО интуитивное или под ним есть что-то существенное? Любопытство не праздное, ибо пока сам сижу на 2k.

Падения производительности не замечал на 2005 либо 2008. Но сравнить объективно было бы интересно

+ При режиме совместимости 2000 (в частности)

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

а в этих ветках о проблемах, именно про связку поздних SQL и секретного релиза?

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

"•не использовать это решение без достаточного тестирования в вашем окружении;" ИМХО достаточно чтоб не рисковать.

Жив курилка (с)!Это к тому что 7.7 до сих пор живет, а проблемы , известные и решенные в начале 2000-х до сих пор обсуждаются.Конечно, SSD тогда не было, но 1500 накладных в 7.7 в день проводили  и распечатывали)).Ищите и обрящите.

Использование режима совместимости позволяет юзать старшие версии СКЛ, 1С все равно не умеет с ним работать. Зато это иногда пригождается при "свое работе с сервером". Я не заморачивался секретными релизами и заказчикам их не ставил.

в sql2005 и выше нет ошибки замедления массового проведения из-за одного этого надо переходить на sql2005 sql2005 и выше если sql 64 то используется sql сервером гораздо больше памяти чем в sql 2000 sql2005 сервер и выше гораздо лучше настраивается например у себя поставил форсированную оптимизацию для баз 1с это дает выигрыш в процентах не скажу. для баз в режиме 80 эта опция не работает. Начиная с sql2008 если есть избыточная мощность процессоров то можно некоторые таблицы (вдумчиво выбирая ) ( например rg )  упаковать. Можно и дальше копать еще глубже но это надо смотреть конкретную базу. также начиная с sql2005 новые операторы языка t-sql все сказаное относиться что база работает в родном режиме (для sql2005 - 90 , для sql2008 - 100 )

+ у 2008 есть ещё немаловажный плюс - он бэкапы на лету сжимает, тем самым время на бэкап в разы уменьшается.

В больших управленческих базах в принципе невозможно массовое перепроведение.

+ Независимо от версии SQL.

SQL плюс "гибкие блокировки" очень недешевое решение. Дешевле выйдет раз в несколько лет менять серверные SSD в зеркале.

Добавлю к при запуске 1С-ки можно в ярлыке настроить параметр (/U) - куда будут записываться временные файлы пользователя. Желательно их тоже перевести на РАМ-диск. Иногда очень хорошо помогает.

/T наверно имел в виду?

У него файловая база, и 32 гига памяти. Зачем ему SSD?

Еще раз настойчиво предлагаю отказаться в оперативной деятельности от работы задним числом - сей простой рецепт _существенно_снимает проблему транзакций/блокировок

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

Какое-же оно узкое? Перешли на SQL, дали ему нормально памяти, и вся база будет в памяти.

зачем скуль при такой мелкой базе ?

быстрее работать не будет, смысл какой ?

Да, что-то скатилось к СКЛ-срачу...

Как минимум стабильность и надежность. И если упирается в диск, то как раз будет быстрее. Тем более размер уже критичный для ДБФ.

см.

(47,48) А что сравнивать в ms sql 2000 Standart у вас серверу доступно 2 Гб памяти ms sql 2005 Standart у Вас на современных серверах будет доступно серверу  памяти от 16ГБ и выше. ну даже если у Вас используется awe ( в sql2000 ) все равно awe c косвенной адресацией будет медленней работать чем просто прямая адресация  памяти в пространстве 64Х

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

А кто нас заставляет ставить стандарт?

скорости точно не будет

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

скорости после перехода с 2000 на 2008 - не замечено тока глюки с монопольным входом

Опять двадцать пять. Если делать по-уму, то и на 2000 базы в памяти.

Ну ну попробуй 1С-кой заставить работать сразу все процы. на 2000 это не проканает.

а память тут при чем? Да и процы все работают.

А ты попробуй восстановление последовательности на 2000 и 2008 и сам увидишь, что на 2000 нагружается только один проц, а на 2008 все что выделены для SQL.

см.

а потоки каких процессов нагружают эти процессоры?

sql сервера? т.е. включен параллелелизм?

Файловая семерка в терминале в разы быстрее семерки на ЛЮБОМ скуле.

+ но со временем упирается в размер файла

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

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

Ничего переписывать на прямые запросы не надо. Выигрыш от прямых запросов копеечный.

А что скуль 7.7. сейчас очень просто купить?

А вообще автор, полагаю у тебя проблема в конфигурации. У меня комплексная, пользователей под 80 довольно активных. Есть файл более 1.2 гига, регистр движения партий. Не скажу, что летает, и блокировки бывают, но не часто. Дисковая система SSD + SAS

эт хтож вам батенка такое сказал? Вы уж извините. Но у меня родные алгоритмы переписаны на прямые запросы. Так выигрыш прямых против родных раз в двадцать. Так что не надо ля ля.

Делай замер производительности. Смотри, где тупит.

+ реально помогает в терминале

Я из этих 20-ти получу десятикратный прирост написав на встроенном языке. Непонятно что ты хочешь доказать. Что типовая написана криво? Это и так всем известно.

Вчера колупался с одной функцией, по замеру у меня например сейчас тупит ТекущийЭлемент.ЭтоГруппа и как ты это перепишешь на встроенном языке? Любое обращение через точку считывает весь объект. Ускорить можно только переписав на запросы.