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

(155) Я ни разу не говорил что 1С++ не повышает быстродействие.
Могу в четвертый раз написать свое утверждение. :)

(156) Проблема в том что будет требоваться не человек со знанием T-SQL, а 1Сник, семерочник, со знанием T-SQL. Коих намного меньше чем просто семерочников.

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

ладно поеду домой уже.

(158) Да ладно. Семерочники же учились где-то. А sql на любой программистской специальности учат..

(158) да и не каждый семерочник предложит 148
тем более в течении 10 минут.

(160) sql несмотря на простое описание самого языка - бесконечен.

(161) Это плохой семерочник. Мои знакомые вроде все знают как делается быстрый аналог регистра сведений привязанный к документам на семерке.

(163) ну да об этом я написал статью
году в 2002 или в 2003
Регистр сведений на v7 (сайт дикого зайца )

Я это впервые увидел в Астор-Торговый дом. В 2002-ом.

(164) Нашел статью - февраль 2003-го. Так что это было придумано до нас :)
Фамилию автора Торгового Дома постоянно забываю. Конфа на тот момент была просто гениальная, куча крутых решений, не только аналог регистра сведений.

(166) ну я как бы придумал регистр сведений
самостоятельно ( я не на что не предендую ) решая конкретную задачу.


ну и потом Придумал РегистрСведений-2 с учетом знаний sql
нигде ее не выкладовал ( может даже файл где то и есть )
но и и других ничего подобного не видел.

Вот что-то у меня штатными методами без излишеств не получилось регистр сведений сбацать.
.
задача простая, есть транспортная накладная (документ) - в ней строки - реализации. Задача: фиксировать факт наличия реализации в трансепортной накладной. чтобы в другой ТН реализацию не вколотили заново...

(168)
Так регистр, одно измерение накладная, на нем отбор движений (для индекса), и ресурс любой, в который всегда пишешь ноль.
Поиск элементарный - Фильтр, и выбратьдвижения.

Можно и графу отбора, но это медленней.

Да фигня
Если не нужна штатная миграция ср-вами УРБД - гораздо приятнее работать со своими таблицами.
Кто не верит - смотрите профайлер... во что превращается запись документа, ваша выборка и проч.

(171) Если работаешь со своими таблицами - то зачем 1С?!
1С тут лишнее звено.

(168) Логика в общем-то простая. Нужный набор измерений. Фиктивный ресурс. И при необходимости реквизит.

Поддержу NS. У меня достаточно оптимизированная конфигурация, в которой широко используется кеширование штатными методами для ускорения. Понемногу переписываю отдельные места на прямые запросы. Сам-то прямой запрос, возможно, и кардинально быстрее штатного работет. Но интересует скорость работы алгоритма в целом, а не отдельного запроса. И тут, зачастую, хорошо если в полтора-два раза ускорилось. Отдельные места, где выполнение запроса занимало львиную долю времени, конечно, ускоряются кардинально, но такие места по пальцам пересчитать можно.

(100)

Функция ВернутьМатрицу()
    стр = "";
  //  ТекЭлемент = ТекущийЭлемент();
     Если ЭтоГруппа() = 0 Тогда
        Если ТипМатрицы = Перечисление.ТипыМатриц.ОсновнаяМатрица Тогда
            стр = "Осн.";
        ИначеЕсли ПустоеЗначение(ТекЭлемент.ТипМатрицы) = 1 Тогда
            стр = "!Пусто!";
        Иначе
            стр = "Внеп..";
        КонецЕсли;
        Возврат стр;
    КонецЕсли;
КонецФункции

В форме списка справочника и элемента и так доступны все реквизиты, не нужен там текущийЭлемент.. вообще.

(176) В моем коде, который ниже - нужен. Для получения остатков из регистра.

Ну и для поиска в ТЗ, хотя в принципе код уникальный, можно искать по нему.

(45) так обосновывать нечего. Нет никакой заточки на sql2000. Следовательно и вывод в (35) неверен.

(179) Невозможно писать под конкретную версию SQL, и не сделать под неё заточку.

На нем происходила отладка и тестирование огромного количества копий программы, и под ним исправлялись все глюки на протяжении почти 30-ти релизов.

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

(182) Я не понимаю о чем ты пишешь. Ты хочешь сказать что SQL-ные пользователи сидели не на SQL2000, не на нем фиксировались косяки, и не под ним исправлялись?
SQL версия 1С 7.7 заточена чисто под SQL 2000, и ничего притянутого за уши тут нет, они писалась и поддерживалась чисто под него.

(183) Вообще-то заточена она была под SQL7.0, а в 2000 уже появились заморочки с неочисткой временных таблиц и как следствие прогрессирующим замедлением работы клиента)

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

(185) Зачем тогда убеждать?
Я отлично знаю, что если ты пишешь и тестируешь в некотором окружении, то в любом случае идет оптимизация под это окружение. Для примера чего стоит фича в SQL2005 с резкими тормозами в журнале подчиненных документов.
(184) Первые релизы - вполне возможно были заточены под 7.0, а последние явно точились под 2000.

(186) "а последние явно точились под 2000"
Вся заточка ограничилась добавлением условия проверки версии сервера, похоже. Ибо обойти тот баг с временными таблицами достаточно несложно было бы.. раз не обошли - значит не затачивали.)

(186) значит секретный релиз расточил заточку.

(188) Секретный релиз исправляет единичные косяки в проседании производительности из огромного количества. Косяк с подчиненными просто на виду.

(187) см. (180)
Когда у тебя в окружении стоит определенная версия скуля, хочешь не хочешь, но произойдет заточка под неё. У подавляющего большинства пользователей стоит 2000-ый, и в 1С начиная с какого-то момента явно стоял 2000-ый.

(187) "Ибо обойти тот баг с временными таблицами достаточно несложно было бы."
не подскажешь несложный способ обойти этот баг на 2000

(187) "Ибо обойти тот баг с временными таблицами достаточно несложно было бы."
Не подскажешь несложный способ обойти этот баг на 2000?
Я знаю только реконнект, но его не отнесешь к простым.

(192) Вроде мелкомягкие пишут тоже что только реконнект.
Это внутренний глюк 2000-го, а не 1С.

(192)+ Если бы 1Совцы взялись за решение этой проблемы, то им пришлось бы реализовать поддержку 2005.
Имхо не стали делать потому, что, когда проблема стала широко известна, 8ка уже была в обороте.

(192) Ну например, не использовать sp_executesql, а использовать обычное выполнение запросов. Разумеется, этот способ работает на уровне платформы. А на уровне конфигурации - только реконнект.

А 32 Гига ОЗУ.. не маловато ли?

(196) Шутите? У нас на старом сервере с 4 гигами 30 семорочников терминальщиков вполне комфортно себя чувствовали..

(196) на 16 ГБ у меня 120 пользователей в терминале + скуль на этой же машине. Летает!
Так что не мало, хотя зависит от базы и алгоритмов

(0) Я уже думал что для всех этот этап пройденный. Сам намучился в свое время очень сильно. УРБД тоже имею но проблем сейчас никаких тьфу-тьфу нет. Сервер у меня примерно такой же, пользователей около 50. Использую кернел33 и кернел37 для решения проблемы с 1 ГБ и для решения проблемы со 100% загрузкой процессора. Юзеры должны быть разделены по папкам обязательно.
Злобчинский подтвердит!!! )))

(195) там, как я вспоминаю, проблема связана не столько с sp_executesql, а сколько с выполнением любой sp в которой происходит insert в tempdb
В таком случаем им бы пришлось отказаться о использования рекурсивной хранимой процедуры для укладывания списков значений и групп в качестве фильтров.
Делать обход иерархии справочника на клиенте и инсертить в темпдб элементы поштучно обычными запросами - тоже так себе выход

(93) Зачем ставить этот патч, если можно всем юзерам выставить время ожидания на блокировку = 0 ?

(201) Зачем получать модельное окно на экран, если можно просто поставить патч Ромикса?

.. в лесу раздавался топор дровосека...
обсуждение скатилось в несущественные вопросы... ;-)

SSD рулит )

(181) что же они явный косяк ВыбратьПодчиненныеДокументы не исправили
как бы к моменту выхода  27 релиза этот косяк был точно известен и причины его тоже известны.
исправлять там программистам 1с от силы час  максимум два.
не исправили скорее  не потому что не могли а не нужно было  улучшать v77.


(186) Проблема подчиненных документов ( уже много раз обсуждалось и на мисте в том числе )
это проблема формирования программой 1с77 к sql запроса.
ошибка одна и та же как и в sql2000 так и в sql2005.
Просто более качественный оптимизатор запросов sql2005
пытается оптимизировать и все равно не может плохой t-sql запрос который
выдает 1с т.е. ошибка есть и там и там просто
пытаясь оптимизировать некачественный sql запрос оптимизитор запросов sql2005
тратит на это гораздо больше времени.



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

(205) а в чем там причина?

(200) "рекурсивной хранимой процедуры для укладывания списков значений и групп в качестве фильтров"
О как! А как эта процедура называется? Что-то в списке хранимых процедур базы ничего подобного не видел..

(206) если не указана конечная дата в ВыбратьПодчиненныеДокументы
то 1с генерирует  конечную дату = '20991230'
Заметьте именно 30 декабря.

(205) Потому что на SQL2000 выборка из подчиненного справочника отрабатывает нормально.

(207) А она временная, создается каждый раз перед укладыванием фильтра в темп

А если бы 7.7 оптимизировали под 2005-ый, то естественно бы поправили.

(207) там используется рекурсивная функция, аналогичная той что и в УложитьСписокОбъектов в 1с++

(209) Блин, подчиненных документов канешн.

(205) Ошибка - это то что отрабатывает неверно, или ведет к снижению производительности. Под SQL 2000 - что ты укажешь второй параметр, что оставишь пустым - скорость одинакова.
То есть это не ошибка, а фича. Заточенность под конкретное окружение.

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

(214) Ошибки есть в любой программе.
Если ошибка себя не проявляет или слабо проявляет это не значит что ошибки нет.
А уж о какой то заточке этого оператора ВыбратьПодчиненгныеДокументы
под sql200 даже и говорить нечего - прочтите внимательно 211

ps   в 216 не 211 а 215

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

(215) Если бы 7.7 оптимизировалась под SQL2005, то этот косяк бы заметили и исправили. Кто знает сколько таких косяков в релизах, и где они повсплывают на крупной базе.

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

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

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

(212) Там временная процедура создается что ли?

(221) Я ничего не обобщаю. И говорю не о принципах создания, а о принципах использования. Если оболочка 7.7 писалась под SQL2000, на ней же тестировалась, и получали сообщения об ошибках от пользователей и партнеров которые тоже использовали SQL2000, то использование под SQL2005 может выйти боком. Никто не знает какие баги выплывут, и в каких местах будут обнаружены провалы производительности.

(222) да

(223)>>>Если оболочка 7.7 писалась под SQL2000, на ней же >>>тестировалась, и получали сообщения об ошибках от >>>пользователей и партнеров которые тоже использовали >>>SQL2000, то использование под SQL2005 может выйти боком.

так t-sql sql2005 является расширением sql200.
ничего они(ms) оттуда вообще не убрали только добавили.
то что переход не приводит к ошибкам это явная заслуга
фирмы MS
и как бы на совместимость продуктов sql200
и sql2005 MS потратило тоже не мало сил и денег.



да и те кто использует 1с с sql2005 и выше как бы не было описание на форумах  суперпроблемм с базами  из за этого перехода.
плюсов же от sql2005 я уже приводил в этой ветке.
и как бы плюсы будут проявляться сразу на любой конфигурации а какая-то никем еще не найденная ошибка на конкретной конфигурации  может никогда и не проявиться
при переходе на новый sql

(225) Только что обсуждали - изменена работа оптимизатора, что вызвало резкое падение производительности при выборке подчиненных документов с невыбранным интервалом.
в каких местах он еще может глюкнуть?

(225) для примера - мы 10 лет работаем на SQL2000, и ни разу не было критических проблем. Работа круглосуточная. Стоимость незапланированного останова от 10000 рублей в минуту. Ты предлагаешь перейти на SQL2005? Если в результате перехода фирма встанет, то твоя репутация будет безвозвратно испорчена.
У тебя есть гарантии что не будет критичных дидлоков, или проседаний производительности которые сделают невозможной работу в условиях десятка тысяч документов в день?

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

(226) В операторе ВыбратьПодчиненныеДокументы()
это ошибка программистов 1с.
причем ошибка давно извесная и уже давно описанная.
для кого она была критической тот ее исправил.

(227) я тебе ничего не предлагаю.
но и не надо других убеждать что MS в ms sql ничего не сделало
в продукте ms sql за 14 лет.
на каждой фирме есть люди принимающие решения и им руководство должно доверять принятие важных решений - вот и все.

(228) вообще не понятно что сказал.

(227) ну тут известный принцип "работает - не трожь".
я вот ща в конторе буду клюшки на скуле заупскать. ясен пень 2000 лицензхионного - хрен где нароешь, анароешь - два скуля на однйо машине держать - хз... вот будем на секретном под 2008.. посмотрим.
.
а все из-за чего - больше года назад предупреждал - хватить на два, может три квартала - интенсифицируйте работу - чтобы можно было обрезать базу и продолжить работать ка кработали.. приходят надысь на прошлой неделе глазенками хлоп-хлоп
- у нас бяка файло 2 Гига
- ну и что хотите?
- сделайте чтобы работало...
- обрежьте базу
- не можем, работы не сделаны...
.. дальше я тему не стал развивать про управление/организацию работ...
.
завтреца вот буду писать гендиру что техотдел ввиду того что использование клюшек предусматривалось только с Sql2000 - не может дать вообще никаких "гарантий"...

(230) при выгрузке справочников используется глюк SQL, для скорости. Что тут непонятного? :)

см (99)

(233) Если пустоеЗначение(АтрибутТаблицы)
дает другой результат чем
Атрибут.Выбран() то это говорит о нарушениии логической  целостности базы данных.

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

ну а в чем плюс пустоеЗначение перед выбран даже не хочу здесь обсуждать.

(234) а в чем плюс выбран() над пустоезначение?!
логическая целостность тут не при чем, это фича 7.7 под SQL.

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

(236) я знаю. поэтому и пустоезначение()

(236) там вообще тип "строка", это же наименование. :)
но вообще везде в конфе пустоезначение() вместо выбран, есно.

(111) Автор, так какой бюджет на "сделать все ок"? :)
Я как-то с трудом представляю как можно тупить на 30 пользователях. Или все роботы?

Мне кажется ключевые слова тут "база самописная" :)

(239) вот и я тоже мучаюсь этой мыслью...

(240) Каждому своё. А я вот мучаюсь мыслью, как бы сделать так, что бы моя "самонапереписанная комплексная" не тупила. :(

(111) Можешь конфу скинуть мне на мыло? В идеале, если можно, с данными. Но можно и без них. Хочу оценить оптимальность алгоритмов.

Повторю (149) Дайте мд-шник посмотреть. Мой ник псина народ ру.

+242. Из личного опыта: как-то оптимизировал отчет на 7.7. Исходное время выполнения составляло 40 минут. Сократил до 6 минут.

(244) Да фиг с ним, с отчетом. Его хоть оптимизировать можно. А что делать, когда загрузка-выгрузка данных по УРБД тормозная? Буквально вчера: на выгрузку порядка 10000 измененных элементов справочника. Около мегабайта архив в результате выгружается. Выгрузка занимает четыре минуты.

(245) не использовать уриб

использовать его только для решгистрации изменений. Выгружать другими средствами, например, по правилам МОД-а.

(241) я вот мучаюсь мыслью - как бы в своих дописках подчистить всякое и до ума довести ряд пунктов...

(241) очень просто - кастрировать аналитику на 41 счете, это для начала.

она там лишняя

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

(0)ну вы хоть выяснили что именно тормозит?
если нет то придется кому-то заплатить )))

(231)начиная с 2008r2 уже можно ничего не резать
настроить скуль + регламенты

(253) Ну почему.. ограничение осталось, только изменился размер.

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

(255) для файловой базы 30 юзверей - это так, чуть выше средненького. с учетом того, что обычно из 30 юзверейгенерят трафик и нагрузку гораздо меньше...