Кто прав, админ или 1С-ник? #477703

Вводная. ТиС дбфная (переделанная), в ней 40 пользователей. В терминале. Размер базы 1.4 гига. После дописывания ТиС модифицированная (я так понял, разделили на 3 юридических лица, создают документы при продаже сразу на несколько юридических лиц, документы создаются одновременно),и начинаются очень серьезные тормоза, пользователи работать не могут. Сегодня весь день контора практически стояла. Админ и 1С ник валят друг на друга. 1С ник говорит, что типа предупреждал, что так и будет после дописывания. Точку зрения админа не озвучивали, но кажется недовольны именно им.  Знакомые попросили завтра приехать, посмотреть че и как, и предложить какое-то решение. С чего начать и какие возможны причины таких тормозов? Я понимаю, что данных маловато может быть, я пока только со слов руководства знаю ситуацию. Ситуация полностью неоднозначная, мне кажется, что в терминале база дбф такого небольшого размера достаточно шустрая должна быть.

Вводная. ТиС дбфная (переделанная), в ней 40 пользователей. В терминале. Размер базы 1.4 гига. После дописывания ТиС модифицированная (я так понял, разделили на 3 юридических лица, создают документы при продаже сразу на несколько юридических лиц, документы создаются одновременно),и начинаются очень серьезные тормоза, пользователи работать не могут. Сегодня весь день контора практически стояла. Админ и 1С ник валят друг на друга. 1С ник говорит, что типа предупреждал, что так и будет после дописывания. Точку зрения админа не озвучивали, но кажется недовольны именно им.  Знакомые попросили завтра приехать, посмотреть че и как, и предложить какое-то решение. С чего начать и какие возможны причины таких тормозов? Я понимаю, что данных маловато может быть, я пока только со слов руководства знаю ситуацию. Ситуация полностью неоднозначная, мне кажется, что в терминале база дбф такого небольшого размера достаточно шустрая должна быть.

>Знакомые попросили завтра приехать, посмотреть че и как, и предложить какое-то решение. С чего начать и какие возможны причины таких тормозов? если не знаешь что делать - зачем подписался... там и без "экспертов" жпо...

У меня есть представление, что делать. Просто как-то непривычно, обычно я работал в конторе с проблемой и у меня было время спокойно разобраться, а тут чуть ли не как эксперта аудитора зовут. Вот и хочу посоветоваться, чтобы ничего не упустить из виду.

На мой взгляд, админ здесь не причем, я замечал что скорость сети вообще довольно слабо на скорость 1 с влияет. Теперь. " 1с-ник предупреждал. " Он что, предупреждал что работать будет невозможно? Тогда значит тем более проблема в 1с, но 1с ник ни при чем тоже, раз предупреждал)  А вообще, похоже надо вернуться к недописанному виду. Кстати, для наглядности можно копию базы недописанной погонять, посмотреть, как она будет вертеться...

кто сильней, тот и прав)

"С чего начать..." Начни с бабла, еще до того как к ним попрешься. Стопудово проблема в нем. "1С ник говорит, что типа предупреждал..." Ну если захотели тормоза - в чем проблема?.. Все вроде понятно. Админ всегда прав.

админ прав. одновременная сплошная запись - вешалка. строить в очередь и сохранять в роботе.

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

Он и предусмотрел : >"1С ник говорит, что типа предупреждал, что так и будет после дописывания" Админ прежде всего царь и бог, и только потом уже пид*рас (с)

сама схема автосоздания в дбф на 77 не фонтан, ставь их на бабки - вам нужен совместитель аудитор с окладом от ххххх

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

>>строить в очередь и сохранять в роботе. Не понял. Можно разжевать? )

почитай ветки из поиска типа "7.7 тормозит"... наберешься идей

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

ну это я вообсче-то шучу) ...  На самом деле 1с ник конечно сказал что-то типа "будет в какой-то  степени подтормаживать", и уж конечно никак не "будет полная ж*па, но я поехал писать код...". А получилась ж*па. У меня на "дополнительной" работе прогерыы написали очень массивную и сложную программу, но она очень тормозная. В принципе работать можно, но поскольку продукт получился довольно "затратный" и т.п., тормоза в общем-то не предполагались... Так что вот - похожая ситуация. Я к тому, что случай не единичный.

Ситуация, когда "кто-то валит на кого-то" уже однозначно нездоровая. Тут надо подходить с другого.

большую и сложную, но тормозную - вопрос квалификации прогов и адекватности принимающего работы.

им нужен аудитор вероятно это я... уж я поставлю их ра... в смысле выстрою им рабочий процесс

Не оптимальный код документов + размер базы.

>адекватности принимающего работы ГБ будет нагрузочное тестирование делать на ЦУПе? - сделал Вася? - угу - молодец, на тебе денег.

ИМХО дописки 1Сника и тормозят. Если раньше не звали, значит не тормозило. А раз сейчас, после дописок тормозит, то явно в них все дела.

, Да в общем вроде понятно все. Админа вообще отбрасываем. 1с ник должен, в зависимости от подхода проверяющего, либо объяснить ситуацию так, чтобы крайним остались какие-то высшие силы - типа "это ж 1с, здесь не угадаешь....", или уж должен быть назначен крайним, как не предусмотревший такое развитие событий, и возможно не оптимизировавший код. >Не оптимальный код документов + размер базы., - это в общем-то похоже, можно попытаться оптимизировать код, обрезать базу.... А может и вернуться к тому что было.

"создают документы при продаже сразу на несколько юридических лиц, документы создаются одновременно" Меня терзают смутные сомнения. А не пытается ли система провести один документ из другого? Если так- рубить голову специалисту 1с. Предупреждал он, шарлатан

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

ОбработкаПроведения Предупреждение("Я же говорил что будет тормозить!", 600);

да скорей всего просто надо сделать в транзакциях и все. Ну еще может быть что там проц нагружает на 100%

О, да Вам в 1С надо работать, типовые лабать.

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

Счетчики производительности системы , может диск из рэйда вывалился , замер производительности в 1с

Повезет тебе , если в 1с проблеммы, раз такое спрашиваешь

Посмотреть, нет ли на сервере Касперского... Если нет, то нет ли вирусяки... Нормальное ли железо... Может софтом облегчить сервак, чтобы на разные мелочи не отвлекался... Чего там со свободным местом на сервере... Чего там с дефрагментацией на сервере... Еще можно у 1С спросить, а чего это ты тут дописал... Может хотелка после таких тормозов отвалится у руководства и можно будет отказаться от доделок-перрделок и работать по старому...

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

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

>>и тут же во всех окнах справочника происходит обновление. в каких окнах, не понял?

В конфигурациях 1с таких ошибок не делают - а вот как оказывается в крупнейших франчах еще как делают..

Мне непонятен не админ не 1с-ник. Почему не сделали пробу запуска для начала на копии? А начальство не боялось экспериментов в живую? Тормоза заключаются в том что когда один проводит документ остальные видят могучее слово Транзакция?

Гризли автор а ещё очень непонятно почему при размере базы больше Гига не переведут dbf на sql? Не ужели оба они не читали книжек где пишут dbf для размера базы меньше Гига, большее MS SQL Server + 1c ? Начальство не даёт бабла на лицензии к SQL Server, тогда какие притензии?

А потому что на мисте нужна еще одна рубрика - "Детский сад"

Для 7.7 польза SQL под боооооооооооольшим вопросом.

Masquerade Так рекомендуют вроде в официальных книгах 1с, которые в комплекте с поставкой 1с+MS SQL Хотя ты прав есть и минусы у SQL+1c: Например долго работает восстановление последовательности, групповое проведение. Но есть и плюс у SQL+1c: у SQL лучше реализован механизм транзакции чем в 1с 7.7. А отсюда при большом количестве пользователей меньше блокировок (транзакций) при попытке провести документ, когда ещё кто-то проводит другие документы. Может и ещё есть + и - у SQL+1c, но вроде основное упомянул.

как вариант можно было переписать запросы по остаткам на прямые.

Перевод базы на скуль в данном приведет к уменьшению производительности.

В официальных книгах много чего рекомендуют.

Дайте плиз хороший хелп по анализу дисковых подсистем. Давно уже делал, многое не помню, щас не могу вспомнить по какой методичке анализировал.

Отладчик прав, и его правая рука - замер производительности.

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

Ну вот и разбирайся... Админ тут вообще ни при чем. Админу надо лишь говорить, что нужно сделать для нормальной работы. Это не его дело, 1С.

Смешно же вообще - админ виноват?:)))

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

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

ИМХО причем тут админ, к сожалению, довольно часто имеет место случай кто громе горланит тот и прав И вообще, где голосовалка?

Да мне плевать кто там в фаворе. Мне интереснее задачу решить.

Деньги тебе не нужны? Ну ты и карась-идеалист...:)))

Нет, не идеалист. И деньги мне нужны. Но не настолько, чтобы говорить что черное это белое, а белое это черное. В конце концов, могут и другого специалиста позвать.

"1С ник говорит, что типа предупреждал, что так и будет после дописывания." Я вобще не въехал, при чем тут админ???

Вопщем коллеги. Ситуация ясна. Разработчик написал немасштабируемое приложение. Админ скорее всего не при делах. Скорость записи на диски надо проверить конечно, большой файл записать/считать (желательно проследить чтобы без кеша ОС, но как в винде это делать не знаю). А девелопер просто не умеет писать масштабируемые приложения. Если автор умеет - то пусть поможет и объяснит девелоперу, но судя по его глупым вопросам о сам нихрена не шарит, нафига едет разбираться? Вероятно, в один момент времени приложение начинает делать множество операций записи, все пытаются писать в одни и теже части данных, перестраивать кучу индексов, причем одни и теже листья индексов. Любое приложение при таком подходе загнется, даже если оно на MSSQL или Oracle. Хотя там гораздо больше инструментов масштабирования. Партиционирование например. О масштабировании надо думать во время разработки, а не после. О чем можно подумать в данной ситуации? Если проблема на записи, то устранить одновременную попытку всех писать в одно место: можно сделать очередь, можно уменьшить количество индексов на таблицах (в 1Цэ где то есть галки на справочниках типа индексируемое поле что-ли) разложить горячие таблицы по разным дискам, если это возможно (но скорее всего немасштабируемость приложения там заключается в том, что параллелизм исключается, и все работает последовательно, как не раскладывай не поможет) Ну а лучше всего редизайн приложения. всем спасибо, все свободны.

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

А не, нашел.

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

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

Работа пользователя происходит медленнее, так как он ждёт, пока другие "сделают своё дело", но в стандартном ожидании 1С тупо лочит файл перед записью, и не выполняет никаких ожиданий - в результате, при записи 1С пишет, а остальные просто "жрут процессорное время" причём очень существенно затормаживая работу того, кто пишет. Если мы вставляем ожидание, то все остальные ничего не делают (если грамотно вставлен вызов ожидания через возвращение системе кванта времени), а один работает - и ему доступно все 100% времени процессора. P.S. можно сделать и без ожиданий, но тогда придётся писать сервер очереди, то есть каждый перед записью будет слать запрос на сервер и ожидать, когда сервер позволит ему выполнить запись (пишется через Socket-ы на раз-два).

Примерно понял. А можно образец кода для примера?

Если почти штатными методами, то всё делается достаточно просто. Процедура ЗаписьДокумента(КонтекстДокумента) ОткрытьФормуМодально("Обработка.ОбработкаОжидания",КонтекстДокумента); КонецПроцедуры В форме: Процедура ПриОткрытии Форма.ОбработкаОжидания("ОжиданиеЗахвата",1); КонецПроцедуры Процедура ОжиданиеЗахвата FsoObject=СоздатьОбъект("Scripting.FileSystemObject"); try  LockFile=FsoObject.CreateTextFile(IBDIR+"WrQueue.lck",0,0); except  Return; endtry; Форма.Параметр.Write;// записываем документ LockFile.Close;// освобоздаем файл Форма.ОбработкаОжидания("",0);// выключаем ожидание Форма.Закрыть;// выполняем закрытие КонецПроцедуры Теперь в каждом месте записи нужно вызвать ЗаписьДокумента P.S. у меня ещё причёсано, то есть в файл пишется имя пользователя, который его захватил, а остальные - читают и выводят на экран сообщение - "Базу занял такой-то". (Только я делал обработку ожидания в форме каждого документа, чтобы пользователь смело мог работать с другими документами, пока ждёт очереди - особенно это касается проведения).

"возвращение системе кванта времени" Мдя..., видно праздник удался на славу. Незабывай иногда выдыхать.

что за олух этот Torquader?! тут у автора ПРОБЛЕМА в том, что никакого параллелизма нет, а все 40 юзеров в одно и тоже время начинаются писать в одно место, и вместо параллельной работы выстраиваются в очередь. >> Ктулху тоже говорил про очередь при записи. Как это делается? Вроде видел >> подобные обсуждения, но чет найти не могу. Технология какая? дурень, не обращай большого внимания на эот. Имелось ввиду сделать отложенную очередь, которую записывать фоном в момент простоя процессора. То есть размыть по времени все одновременные попытки записи. Но это полумер. Самое важное это редизайн приложения. Надо стремиться к параллелизму, а у вас очередь. Есть неокторое очень гоячее место. Это надо лечить.

"тут у автора ПРОБЛЕМА" У автора как раз нет проблемы. Но наслушавшись некоторых "умных" советов - вполне могут возникнуть. Применять нанотехнологии для решения задачи еще непредлагали? А вдруг поможет... Все уже по клюшкам давно известно. Все узкие места и затыки пройдены. Читайте мануали и снизойдет на вас озарение. А решать такого уровня задачи тут за вас никто небудет (это стоит денег и виртуально никак нерешить). 1С - зло.

Автору рекомендуется научиться разбираться, тормозит ли железо и пользоваться perfmon-ом. Читать: Форум по серверам для 1С: Здесь смотрим, какие счетчики использовать в perfmon (четвертый ответ сверху) Можно даже задать свой вопрос типа "Тормозит ли сервер?" - специалисты ответят.

пришел умник, говорит какие-то немыслемые вещи про 1с

очнитесь, люди. Попробуйте работать одновременно 40 пользователями в ТиС под dbf без применения ВК.

ЖЭсть реально. еще спорят. БДФ база на 40 юзеров...какие тут споры могут быть.

ну тут наверное большинство ларьки автоматизируют, и не знают, что это такое

Ну дык проблемы возникли после _дописывания_ ТиС

Хотя база ДБВ на 40 юзеров конечно жесть, и возможно железо у них слабое (из жадности)

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

Проверка мощности железа необходима для решения задачи. Если железо достаточно мощное для 40 пользователей - в тормозах виноват 1Сник. Если железо слабое - виноват админ/жадное руководство

в таком случае можно любую  задачу свалить на железо

Судя по <<я так понял, разделили на 3 юридических лица, создают документы при продаже сразу на несколько юридических лиц, документы создаются одновременно>> 40 физичеческих юзеров волшебным образом превратились в 120 виртуальных.

Примерно известно, какое железо должно быть на 40 пользователей -см.. Так что не свалишь.

на 40 рыл бдф база никакое железо не спасет. хоть тресните.

и дописка тоже нипричем.

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

Если жежезо хорошее - виноват в тормозах 1С-ник, что не перевел базу на SQL.

причем тут 1сник. это вопрос бюджета фирмы.

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

Ну вот у меня сервер в терминале работал медленнее, чем обычная персоналка. И я таки добился, чтобы купили нормальное железо.

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

а еще с тем качеством как написаные семерочные конфигурации так вообще жэсть.

Масштабирование не причем. Сам неоднократно предупреждал в подобных случаях. И приходилось либо ставить галочки, для возможности отключать подобное либо в правах менять, чтобы не у всех тормозило. зы Это были варианты динамического отражения состояния заказов. Но подобных вариантов - масса. Характерно, что тормозит у всех, а причина - какие-либо юзеры, который вообще не жалуется. И если не знаешь, то хрен найдешь.

Посоветуй перейти на 8.2)))

В общем, в саму серверную я не попал.  Админ с утра свалил, серверную закрыл, по телефону послал. ) Пришлось подключаться в терминале с клиентского компьютера, все, что там можно было увидеть, диспетчер задач с загрузкой процессора, да запустить конфигуратор с отладчиком. Загрузка процессора практически постоянно 3-5%. По всей видимости все упирается в дисковую подсистему, но счетчик перфмон я запустить не смог, ибо прав не было у этого пользователя. Райд у них стоит, но какой они не знают, сказали что вроде райд 5. Контроллер вот такой. При анализе замером производительности в 1С видно, что 65% времени занимает Записать в Реализация купли продажи в ТиС. Схема там такая, что 3 конторы, продажа идет с двух контор по отдельности для юриков, по отдельности для частников и в случае если остатков нету, то создается сразу поступление с других юриков вместе с реализацией. При анализе по самой сложной схеме, когда сразу создается и поступление с другого юрика, и реализация, 15% занимает запись поступления ТМЦ, и где то по 25% запросы по регистрам. Т.е. надо смотреть еще и насколько оптимальны запросы по регистрам. Но по сути это очень нездоровая ситуация, когда запись реализации занимает 65% времени.

Задачи 1Снику ставит чисто админ, с руководством это практически не обсуждается. Откат на старую версию был не предусмотрен. Плюс тормоза в 1С сопровождаются глюками с принтерами, когда они вообще перестают печатать. Судя по логам (доступны были) проблему решали неоднократной перезагрузкой сервера.

вообщем ты не справился

Ну почему. Все что я думаю по этому  поводу, какие возможные проблемы и варианты их решения, я рассказал. Что тут 1С ник виноват скорее всего, и надо блокировки применять. Если райд 5 (а там SATA диски) то это тормоз в общем то. Желательно Райд 1+0 на скази. Сколько стоит обновить дисковую подсистему? А хз, это считать надо имея доступ к серверу и имеющемуся оборудованию.

в общем, как обчно все... 1С-ники обосрaLись, стараются все свалить на админа.

Неправильно ты понял чувак.

я же тебе говорю, перепиши запросы на прямые, на порядок проведение ускоришь

В дбф версии? )

да

А дальнейшее сопровождение?