SQL2008 + 1c77, 100% загрузка CPU сервера пока не зайдет админ в 1С #499624

вопросы запуска тут не обсуждаю, перегнал базу в 2008, всё запустилось само, делов не знаю :) проблема уже была описана здесь: у меня в точности это же происходит на 2008 SQL. Раз на раз не приходится, иногда возникает трабл, иногда нет. Если возникает - то возникает у всех (косяк проявляется со стороны SQL), любое обращение к базе любого из пользователей вызывает 100% загрузку одного процессора на сервере секунд на 10-30. Если проблема проходит - то проходит так же резко у всех (после входа в 1С пользователя с админскими правами). Кому-то удалось понять корни проблемы и почему она снимается запуском 1С? Сам склоняюсь к тому, что косяки начинаются когда пользователь обращается всё к тем же подчиненным документам. Но иногда начинается, а иногда нет - всё летает. И как проблему может устранять вход нового пользователя в 1С? нипанятна...

вопросы запуска тут не обсуждаю, перегнал базу в 2008, всё запустилось само, делов не знаю :) проблема уже была описана здесь: у меня в точности это же происходит на 2008 SQL. Раз на раз не приходится, иногда возникает трабл, иногда нет. Если возникает - то возникает у всех (косяк проявляется со стороны SQL), любое обращение к базе любого из пользователей вызывает 100% загрузку одного процессора на сервере секунд на 10-30. Если проблема проходит - то проходит так же резко у всех (после входа в 1С пользователя с админскими правами). Кому-то удалось понять корни проблемы и почему она снимается запуском 1С? Сам склоняюсь к тому, что косяки начинаются когда пользователь обращается всё к тем же подчиненным документам. Но иногда начинается, а иногда нет - всё летает. И как проблему может устранять вход нового пользователя в 1С? нипанятна...

ну собирите статистику скл профайлером (только вместе с планом запроса) И раскажите про решение (какие индексы изменили, какие секционировали)

не замечал такого может дело всетке не в 2008

При работе с нештатным софтом может происходить все что угодно...

есть такая фигня, менял некоторые индексы, но это только общее здоровье, а эффект ступора сохранился, с применением ИБП на недосервере несколько снизилась частота его появления, но само явление не пропало, специальный человек заходит и выходит из базы - с какой периодичностью не спрашивал, просто сказал будешь облегчатором )))

сравнил планы при тормозах и без них - разницы не увидел как я понял по профайлеру (из того, что потестил) тормоза на этих операциях: exec sp_cursorfetch 180150049,1,0,1 так да, если бы проблема была в индексах - она бы не пропадала от входа пользователя :) Что неужели всё так плохо и нас только двое с этой проблемой на весь рунет? :) надо тогда найти, что есть общего в наших конфах :) у меня сильно переписанная комплексная. У меня очень активно используются подчиненные документы. Так вот, если нет ничего открытого, что может обращаться к подчиненным документам, то трабл не возникает! например, когда идут тормоза, если ни у кого не открыто ничего, что может обращаться к подчиненным документам, то справочник номенклатуры работает очень быстро. Наблюдается ли у Вас такое? у меня в журналах есть графы отбора (по большей части остались с тех времен когда база была 10 гиг на dbf :) ): Контрагент: половина документов по полю контрагент И! есть такое:

коряво текст отформатировался, всё что отформатировалось под модуль 1С читать как просто текст (описаение граф отбора)

дело не в сетке, плохая сетка не может загрузить проц SQL-сервера на 100% :)

Сколько всего документов в базе ? select count(*) from _1sjourn(nolock) сколько приращений документов в день. Опиши железо сервера. сколько пользователей работает. Какая операц. система под sql как часто обновляется статистика. Самый простой способ для тебя пеерписать подчиненые документы через прямой запрос 1с++.

в базе 1,7 млн документов прирост: 1000-2000 док-в в день сервер: 2 4-хядерных оптерона 2.8, 16 гиг памяти, под файл базы рейд 10 на сас-винтах (чтение 250-400 мб/с), всё остальное на другом разделе на зеркале. пользователей нет, пока тестирую :) по статистике мои знания очень скупы, могу только сказать, что перепробовал комбинации "автоматическое обновление", "Автоматическое создание", "Асинхронное обновление" - изменений нет. Сейчас стоит создание true, обновления - false. реиндекс базы делал, эффекта ноль. Переписать на 1с++ не проблема. Гемор, но не проблема. Проблема в том, что проблема то есть, то нет... работает же всё через раз :( --------------------------------------------------------- сейчас посмотрел фрагментацию индексов - есть некоторые до 70% доходят. Прогнал следущий код, SQL написал, что отработал, написал где-то ребилд, где-то реорганизе, но фрагментация не изменилась :( -- Ensure a USE <databasename> statement has been executed first. SET NOCOUNT ON; SET @db_id = DB_ID(N'ACT'); -- Conditionally select tables and indexes from the sys.dm_db_index_physical_stats function -- and convert object and index IDs to names. SELECT    object_id AS objectid,    index_id AS indexid,    partition_number AS partitionnum,    avg_fragmentation_in_percent AS frag FROM sys.dm_db_index_physical_stats (@db_id, NULL, NULL , NULL, 'LIMITED') WHERE avg_fragmentation_in_percent > 5.0 AND fragment_count > 0 AND index_id > 0; --В строке выше указываем процент фрагментации ниже которого таблицы не трогаем --и количество фрагментаций, процент может быть большой при маленьких индексах -- Declare the cursor for the list of partitions to be processed. DECLARE partitions CURSOR FOR SELECT * FROM #work_to_do; -- Open the cursor. -- Loop through the partitions.        FROM sys.objects AS o        JOIN sys.schemas as s ON s.schema_id = o.schema_id        WHERE object_id = @objectid AND index_id = @indexid; -- 30 is an arbitrary decision point at which to switch between reorganizing and rebuilding. -- Close and deallocate the cursor.

SQL 2008R2 стоит на 2008 сервере (стандарт)

избавление от дефрагментации поможет но не спасет (  дефрагментацию и обновление статистики лучше делать всегда каждый день ночью) проблема началась с sql2005. точнее проблема не в sql а в плохом запросе который генериться из 1с когда НЕ ЗАДАН интервал подчиненных документов старшая дата береться равной 30.12.9999 ( а надо 31 или вообще не ставить это условие). Проблема решения : Если стандартный 1с то всегда в журналеПодчиненных документов выставлять интервал дат ( Для встроенного языка ВыбратьПодчиненныеДокументы тоже всегда ставить диапозон дат. Если нужна производительность то перепиши через 1с++ пример смотри здесь Почему то работает то нет Описание относиться когда нет доработток : Если таблица _1sjourn расположена в буфере данных то работает быстро(когда входит второй пользователь она подгружается в буфер) иначе sql2008 вынужден прогнать всю _1sjourn через буфер данных а это и есть время а при слабой дисковой системе полная и загрузка процессора.

у меня база на порядок меньше

чтото слышал про приблуду, перехватывающую 1С-ные запросы.. у Ромикса вроде

к теме не имеет отношения

нечто похожее у меня недавно было на 2005... и там тоже Оптерон..

у мне дуо, проблема давняя и на 2008 впереди планеты всей был

там запрос из формы журнала перехватывается ВК и отправляется уже свой переделанный.

похоже, если в тоже много ВыбратьПодчиненныеДокументы в моей конфе вовсю задействовано ВыбратьПодчиненныеДокументы

это понятно, но тема как понимаю о нахождении первопричины ?

у тебя используется ВыбратьПодчиненныеДокументы активно в журналах и доках ?

седня специально понаблюдаю за 2008.. не замечал за ним такого но там, по моему, вапче подчиненные доки не используются))))

Да, вовсю используются!

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

смотри в той ветке пост 14 нет никакого перехвата. + к 14 надо добавить если Дата (как нач и конечная ) пустое значение то не включать это условие в sql запрос. работает на порядок быстрее чем ВыбратьПодчиненныеДокументы + нету нагрузки на sql сервер.

походу оно спасибо и автору буду думать

вот ссылка по теме, вроде человек решил проблему дефрагментацией индексов

наверное выполню через АДО

а тормоза действительно идут именно на этих операциях: FETCH API_CURSOR0000000000000010 exec sp_cursorfetch 180150049,1,0,1

где то год назад было обсуждение этого на форуме 1сpp. Причина в том что запрос к sql "кривой"  + база в формате 80 а это значит что оптимизатор запросов ( работает в режиме эмуляции ) не может это переварить.

в режиме 90 может ?

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

для sql2008 штатный режим 100. У меня нет sql2008.

про переиндексацию и.т.д прочти ветку (особенно в конце )

ну в режиме 100 есть вероятность что "переварит" ? (о том что для адинес нужен 80 пока не думаем)

как закладка ставится ?

Вопрос из 34 как то непонятен. поясни вопрос.

если поставить режим работы 100 (то что для адинес надо 80 - будем считать, что пропатчили так, что хавает любой) - то траблы не будет ? И еще, а Док.ВыбратьДокументы такие же проблемы вызывает ?

Ихххааааа!!!!! 1. беру общий журнал, перебираю все вхождения ВыбратьПодчиненныеДокументы, и везде конструкцию ВыбратьПодчиненныеДокументы(,,Док.ТекущийДокумен) меняю на ВыбратьПодчиненныеДокументы(Док.ДатаДок,Дата("31.12.37"),Док.ТекущийДокумент). Пробую - работает! 2. тормоза при открытии реализации (она всегда проверяет свою СФ), закомментил поиск СФ - реализация стала открываться быстро! 3. заявка покупателя. У меня она при старте проверяет нет ли на её основании реализации, и плюсом проверяет наличие подчиненного документа "ДнфицитТовара". Переправил как в 1 - открывается сразу! итого - никаких АДО не надо чтобы запустить, работы на час если вдумчиво и с пивом :) Z1 спасибо огроменное!!!!!

не знаю. склрее всего да потому что запрос плохой. Это легко проверить(если конечно есть на это желание и время). 1.Надо либо самому через профайлер ( либо уже есть в форумах тот запрос какой генкриться для подчиненных документов с пустой датой ) получить план этого запроса в базе формата 80. Перевести базу в формат 100 ( естественно что никто не должен в это время работать с базой) получить план этого запроса в базе формата 100. Перевести базу обратно в 80. Обновить статистики ососбенно по используемым индексам и Все тоже самое проделать.

ответ в том, что 2005 и 2008 SQL при некотором стечении обстоятельств выбирают неправильный план выполнения запроса при поиске подчиненных документов. в 2000 такой проблемы нет. Кроме того, зависит это всего лишь от параметров для этого запроса. решение - предлагать заменять план запроса На своей базе, взял параметры когда не тормозит и написал вот такой скрипт    @name = N'_1SJOURN_Optimization',    @stmt = N'Select JOURN.* from _1SJOURN JOURN(NOLOCK INDEX=ACDATETIME), _1SCRDOC CRDOC(NOLOCK INDEX=PARENT) where JOURN.DATE_TIME_IDDOC=CRDOC.CHILD_DATE_TIME_IDDOC and CRDOC.MDID=@P1 and CRDOC.PARENTVAL=@P2 and CRDOC.CHILD_DATE_TIME_IDDOC>=@P3 and CRDOC.CHILD_DATE_TIME_IDDOC<=@P4 order by CRDOC.MDID, CRDOC.PARENTVAL, CRDOC.CHILD_DATE_TIME_IDDOC',    @params = N'@P1 int,@P2 char,@P3 char,@P4 char',    @hints = N'OPTION(OPTIMIZE FOR (@P1 = 1824, @P2 = ''E1  W3    W4           '', @P3 = ''20090101     0     0   '', @P4 = ''20091231FHML6O     0   ''))';

я уже то же колбашу по поводу пустот ))) - Огромное тебе Человеческое Спасибо ! самому было вломы думать - а есть еще те кто мыслит )))

то же вариант, тока сильно "фиксированный"

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

>>>>итого - никаких АДО не надо чтобы запустить, Я нигде не предлагал ADO ( прошлый век правда свой первый запрос написал именно на ADO но тогда даже Радуги не было). надо использовать 1срр. 1с++ использует родное соеденение с базой sql. Т.е. sql сервер не различает пришел запрос из встроенного языка 1с или это прямой запрос 1сpp Простой пример поясняющий суть. Предположим есть документ и у него 100 подчиненных документов Тогда если написать на 1с Док.ВыбратьПодчиненныеДокументы(Дата1,Дата2,КонкретныйДоукмент); Пока Док.ПолучитьДокумент = 1 Цикл КонецЦикла; то на sql сервер уйдет как минимум 100 запросов на каждый полученный документ и один тот самый "не оптимальный" который получает все эти 100 итого имеем как минимум 101 sql запрос на sql сервере. Если написать на 1cpp  на sql сервекр поступит и выполниться только ОДИН sql запрос. От этого выиграет как и конкретная сессия так и в целом общая нагрузка на sql сервер будет значительно ниже.

А какие внешние компоненты используются? Может оно и висит, пока админ не зайдёт и не запустится компонента?

оно висит потому что не 2000 SQL Server

не попал про АДО моя сказал, ибо нет 1с++ или на случай отсутствия таковой

когда нет конечной даты нет то @P4 = ''99991230  !!! Вот от такого параметра и начинается колбаситься sql сервер пытвется найти оптимальный план и.т.д. и.т.п.

думаю как оставить такую конструкцию (может кто наведет на мысли)

+ без родного Док.ВыбратьПодчиненныеДокументы в глВыбратьПодчиненныеДокументы

да, но вместо того чтобы менять конфигурацию, как по мне проще один раз создать plan guide

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

и после обновления конфы не надо. один раз для загруженной базы

блин, в базу знаний кто-нибудь добавьте. ау! модераторы!

этот скрипт для 2005 используется? Сообщение 1018, уровень 15, состояние 1, строка 1 Неправильный синтаксис около "INDEX". Если имелась в виду часть табличной подсказки, то для этого теперь необходимо использовать ключевое слово A WITH и круглые скобки. Правильный синтаксис см. в электронной документации по SQL Server. Сообщение 10516, уровень 16, состояние 1, процедура sp_create_plan_guide, строка 20 Невозможно создать структуру плана "_1SJOURN_Optimization", так как не удалось скомпилировать @module_or_batch.

Совместимость с SQL 2k у БД указал?

да

да, для 2005. видимо ему не нравится JOURN(NOLOCK INDEX=ACDATETIME) надо типа JOURN WITH (NOLOCK INDEX=ACDATETIME) Но вопрос в другом: как же тогда 1С запросы работают, ведь там нет этого ключевого  слова...

в профайлере интересно какой запрос идет...

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

+ чиста догадки даже не на кофейной гуще

по идее нет, может быть просто процедура sp_create_plan_guide таким образом запрос разбирает. Но у меня нет под рукой 2008 чтобы проверить. Ждем автора...

>>>Но вопрос в другом: как же тогда 1С запросы работают, ведь там нет этого ключевого  слова... База 1с для sql2008(sql2005) работают в формате 80. Для формата 80 - язык t-sql sql2000 а в нем with является необязательным и with никодга не выставляется из 1с Также оптимизатор запросов Может посчитать запрос с with и без with как разные запросы и снова получим subj.

если там формат 80, почему же ошибка возникла в - вот что странно

а что будем попробовать? запустить скрипт с "JOURN WITH" под 2008 SQL, и когда он его примет проверить опознает ли скуль запрос из 1С по нашей маске? база 80 формата

+ добавил 2 with - скрипт отработал, обращения к подчиненным журналам виснут. видимо = true :-D

Простите пожалуйста - а никто не подскажет с чем связано ограничение на режим совместимости базы с 2000 SQL и почему нельзя запускать в режиме 2005 (9.0)?

ну вот видимо потому и нельзя, что на запросы 1С SQL будет отвечать через раз "синтаксис эррор" :)

а скрипт нельзя как-то модифицировать с подменой по типу ВК romix-а, типа получил запрос без With - выполняй с with, параметры вот такие?

смотри 63

профайлером отлови текст запроса когда подчиненный документ открываешь - какой он?

смотри пример если база в формате 80 ( sql2005,sql2008) то можно написать так Вариант 1 JOURN WITH (NOLOCK INDEX=ACDATETIME) а можно так JOURN (NOLOCK INDEX=ACDATETIME) 1c.exe генерит всегда  без witj если база в формате 90 ( sql2005,sql2008) то вариант 2 Неприемлим (только Вариант 1 )когда опций больше одной и это есть синтаксическая ощибка запроса. А значит запрос не выполниться. Как правило 1с.exe на таких ошибках происходит вылет программы. также насколько помню 90,100 для списка with Желательно в качестве разделителя опций использовать не пробел а запятую т.е вместо WITH (NOLOCK INDEX=ACDATETIME) более граммотно надо писать так : WITH (NOLOCK,INDEX=ACDATETIME)

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

а текущая база выбрана 1С или master при выполнении запроса?

1C такой же как у всех запрос :) отловил: Select JOURN.* from _1SJOURN JOURN(NOLOCK INDEX=ACDATETIME), _1SCRDOC CRDOC(NOLOCK INDEX=PARENT) where JOURN.DATE_TIME_IDDOC=CRDOC.CHILD_DATE_TIME_IDDOC and CRDOC.MDID=@P1 and CRDOC.PARENTVAL=@P2 and CRDOC.CHILD_DATE_TIME_IDDOC>=@P3 and CRDOC.CHILD_DATE_TIME_IDDOC<=@P4 order by CRDOC.MDID, CRDOC.PARENTVAL, CRDOC.CHILD_DATE_TIME_IDDOC кстати я его еще блокнотом нашел в bkend.dll :-D можно наверное там добавить with :-D что хочу сделать - заставить SQL получать запрос с with чтобы сработал план оптимизации. А как этот план увидеть в самом SQL? где он там? запросами вижу, что он есть, а в меню найти не могу.

тьфу, к последний ответ, я поставил

Ну как успехи ? Смогли победить не совместимость платформы 7.7 со SQL 2005 и 2008 + т.д. последующие версии продукта :) ?

+ а HEX-редактором не нашел запрос в dll... ну может оно и к лучшему, тему не закроют :-D

да что такое :) к хотел добавить

with Вам не поможет все дело в @P4. когда нет конечной даты запрос должен выглядеть так Select JOURN.* from _1SJOURN JOURN WITH(NOLOCK INDEX=ACDATETIME), _1SCRDOC CRDOC(NOLOCK INDEX=PARENT) where JOURN.DATE_TIME_IDDOC=CRDOC.CHILD_DATE_TIME_IDDOC and CRDOC.MDID=@P1 and CRDOC.PARENTVAL=@P2 and CRDOC.CHILD_DATE_TIME_IDDOC>=@P3  order by CRDOC.MDID, CRDOC.PARENTVAL, CRDOC.CHILD_DATE_TIME_IDDOC Когда нет ни начальной даты ни конечной так Select JOURN.* from _1SJOURN JOURN WITH(NOLOCK INDEX=ACDATETIME), _1SCRDOC CRDOC(NOLOCK INDEX=PARENT) where JOURN.DATE_TIME_IDDOC=CRDOC.CHILD_DATE_TIME_IDDOC and CRDOC.MDID=@P1 and CRDOC.PARENTVAL=@P2 order by CRDOC.MDID, CRDOC.PARENTVAL, CRDOC.CHILD_DATE_TIME_IDDOC Далее использование для внутреннего соедениния старого стиля никак не способствует составлению оптимального плана выполнения (рекомендация MS использовать INNER JOIN ) Вы как то не последовательны то хотите горы свернуть переписать bkend.dll , использовать перехватчик запросов и все это с неизвестным результатом с другой стороны когда Вам предлагают готовое работающее решение в виде 1сpp то на его изучение у Вас нет времени.

О какой несовместимости речь ? Конкретно запрос обсужаемый в теме "корявый" для любой версии sql сервера. то что sql2000 как-то с этим запросом справляется а sql2005, sql2008 нет, это не значит что есть несовместимость (запрос плох и для sql2000) а на мой взгляд означает что есть "плохой" t-sql запрос можно считать это фичей 1с приложения. Другое дело что 1с ни признают это ошибкой ни тем более не будут это исправлять.

возможно я увлекся, учту критику. с другой стороны, рассуждения "Предположим есть документ и у него 100 подчиненных документов" считаю своего рода спекуляцией :) у меня очень редко когда бывает больше 4х подчиненных документов, кол-во таких длинных деревьев из документов не превысит 3% от общего числа, и в этих 3% там кол-во документов в пределах 10.

в 44 число 100 было выбрано специально чтобы более ощутимо можно было увидеть преимущество 1сpp. Хорошо если есть четыре подчененных документа у конкретного документа то выполнение одного sqlзапроса вместо как минимум 5 sql запросов это большой выигрыш ( тем более этот единственный запрос лишен недостатка по Если говорить о деревьях ( И если у тебя нет какой-то супер специфики) то на 1cpp где-то есть обработка (автор orefkov) получает все дерево подчинения одним sql запросом.

Вот еще ссылка разъясняющая полностью subj и цитата от туда же :                                                       Glory

в коллекцию

не прав Glory - пусть скульщики заядные понапишут стока запросов скока в адинес реализовано - они просто сдохнут, конечно когда таблицы и т.д. чуть ли не руками выстроены говорить о "правильных" запросах просто, ибо их будет с десятка полтора, а вот когда таблицы и потребности могут быть различны - тут тока базары или адинес/сап и т.п.

Ветку в Бздню, отмечать не понятно как и что, но попытаю и верните ИЗ, а стукача повешать !

без 1с++ никак не обойтись! И дело не в количестве подчиненных документов, а в отборе по датам. Сравнивал: выборка подчиненных документов на 1с++ выборка подчиненных с указанием интервала (Док.ДатаДок, Дата("31.12.37")... выборка подчиненных с указанием интервала (Дата ("01.01.06"), Дата("31.12.37")... выборка подчиненных с пустыми датами первый вариант и второй при работе с документами в конце журнала (по дате) глазом разницу не видно, но будем считать что она есть :) третий вариант по скорости близок к последнему (подозреваю, что все 1,7 млн документов проверяются по дате попадают ли они в выборку). Но второй вариант вырождается в третий при работе с достаточно старыми документами!

В ссылке из написано, что 1с++ в общих журналах не решает проблему - частично подтверждаю, на 2000 SQL общий журнал работает быстрее, но не на порядки, а в разы. Т.е. в принципе работать теперь вполне можно. осталось переписать оставшиеся 94 вызова ВыбратьПодчиненныеДокументы в эмдэшнике и отловить и переписать все их во внешних отчетах :)

: подозреваю что ступлю но все-тки спрошу. а что, в 1с++ не получится слепить какой-нито класс "подчиненныедокументы" чтобы только "создатьобъект" поменять понадобилось в коде (методы "выбратьподчиненныедокументы", "получитьдокумент" чтобы были с таким же синтаксисом)?.. ЗЫ: ну или гуру попросить нарисовать ВК которая реализует объект подчиненного документа с быстрыми выпорками?..

просить гуру - не наш метод :) В общем за каких-нибудь 10-12 часов я всё переписал, уже запустился на новом серваке. Сейчас в базе 84 пользователя, всё работает. в половине случаев или даже больше вместо выбора подчиненных я использовал следующую функцию:

CLOSED=1 не всегда =1 у проведенных документов, всё зависит от набора компонент.

+92 нафига делать глМД.ЗначениеИзСтрокиБД ? когда проще в самом запросе типизировать?

да! спасибо! исправлю на >0 подскажите пожалуйста как это сделать, я использовал готовый код (переписывал), там было использовано ЗначениеИзСтрокиБД.

TabJ.IDDOC [Док $Документ]

спасибо! попробую и такой вариант.

оберни в класс