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

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

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

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

Сервер какой, терминал?

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

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

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

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

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

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

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

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

(4) Мне кажется надо регистр закрыть :)
Тут способы ускорений:
http://1c911.by/uskorenie-1s-77.htm#4

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

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

подчистить базу вот этим
http://infostart.ru/public/180018/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(27) 2+2 = 3.9999999999999999

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

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

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

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

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

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

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

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

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

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

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

Но всё это только в случае, если у вас хороший и правильно настроенный UPS. Если нет - вы этих советов не видели.

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

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

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

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

(41) "Но всё это только в случае, если у вас хороший и правильно настроенный UPS..."

...А также хорошая и правильно настроенная ОС, хороший и правильно настроенный кондиционер в серверной и хорошая база, которая позволяет потерять часть вбитых данных.


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

На самом деле SLQ + "гибкие блокировки" помогут избежать долгих ожиданий на записи.

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

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

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

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

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

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

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

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

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

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

(42) в sql2005 и выше нет ошибки замедления массового проведения из-за одного этого надо переходить на sql2005

sql2005 и выше если sql 64 то используется sql сервером гораздо больше памяти чем в sql 2000

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

Начиная с sql2008 если есть избыточная мощность процессоров то можно некоторые таблицы (вдумчиво выбирая ) ( например rg )  упаковать.


Можно и дальше копать еще глубже но это надо смотреть конкретную базу.

также начиная с sql2005 новые операторы языка t-sql

все сказаное относиться что база работает в родном режиме
(для sql2005 - 90 , для sql2008 - 100 )

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

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

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

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

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

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

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

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

(0) узкое место одно - дисковая система. Какая она у вас хоть ?

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

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

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

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

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

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

см. (4)

(47,48) А что сравнивать в ms sql 2000 Standart
у вас серверу доступно 2 Гб памяти

ms sql 2005 Standart (64) у Вас на современных серверах
будет доступно серверу  памяти от 16ГБ и выше.



ну даже если у Вас используется awe ( в sql2000 )
все равно awe c косвенной адресацией будет медленней работать
чем просто прямая адресация  памяти в пространстве 64Х

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

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

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

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

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

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

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

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

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

(81) см. (58)

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

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

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

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

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

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

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

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

(0) А вообще автор, полагаю у тебя проблема в конфигурации.

У меня комплексная, пользователей под 80 довольно активных.
Есть файл более 1.2 гига, регистр движения партий.

Не скажу, что летает, и блокировки бывают, но не часто.

Дисковая система SSD + SAS

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

http://kb.mista.ru/article.php?id=179

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

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

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

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

(97) Приведи пример.

Для примера
ТекстЗапроса="спр=справочник.контрагенты.текущийэлемент;  
    |Наименование=справочник.контрагенты.наименование;
    |Группировка спр;";
    Запрос.выполнить(ТекстЗапроса);
    ТЗ=создатьобъект("ТаблицаЗначений");
    Запрос.выгрузить(ТЗ...
Пока ТЗ.Получитьстроку()=1 цикл
Если пустоезначение(ТЗ.наименование)=1 тогда
// не поверишь, но это группа. Фича SQL.

(98) Да любая функция на форме где нужно что-либо вывести для текущего элемента, проверяется не группа ли это и соответственно выполняется код.

Грубо говоря

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

ТекЭлемент.ТипМатрицы -- тут полное считывание объекта, все реквизиты, периеодика и прочее

Автор топика давно слился.
.
а с учетом того, что так и не последовало внятного ответа - работает база в ТА или преимущественно колбасят задним числом - фиг ли здесь обсуждать

(99) Это все замечательно, а если на каждую строчку в подборе нужна проверка?

(101) Обсудить всегда есть что.

Или свертка ТЗ с итогами по группировкам, какой самый быстрый способ?

(100) При использовании 1с++ это всё кэшируется.. есть там такая фича..

+104 простой способ группировать с помощью индексированной табличке, но если данных много начинается немного притормаживать, быстрый способ на скуле получить через with rollup

Еще к примеру 1С применяет линейный поиск по именам. 1С++ же везде меняет это поведение на хэш.

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

(97) Что значит "тупит"?
Может она вызывается 100500 раз?

(104) Пробовал и виз роллап и свертку в ИТЗ - все приемлемо работало
Задача то какая?
С ИТЗ очень просто потом работать и универсально, если много данных надо специфически быстро обработать, а не тупо вывести - заливаю в таблицы СКЛ и там кручу.

(108).1 Понятное дело что она вызывается 100500 раз, а как иначе для функции на форме подбора? сколько вылезло товаров на экран столько и выполнилось.
(108).2 Больше 5 группировок Индексированная становится узким местом у меня, запрос по отчету выполняется 3 секунды, группировка 40 секунд грубо.

"С ИТЗ очень просто потом работать и универсально"

с этим никто не спорит.

Сейчас речь о сравнении штатных методов против костылей.

Я правда не понял NS против только прямых запросов или любых внешних компонент и классов к коим относится 1с++.

(101) база самописная, регистры не используются. Блокировки и тормоза при записи документов. Поразгонял пользователей по разным базам с обменом раз в час стало заметно полегче. Топик читаю (не слился)

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

(111) Переходите на 8.х тама меньше блокировок.

+(112) но и железо придется крутое брать, она зараз ресурсы жреть мама негорюй!

(111) Журнал у тебя в любом случае будет блокироваться при записи тут ничего не поделаешь. Ожидание захват табличек поставить в 0 чтобы колом все не вставало.

(111) Отказались от регистров - отказывайтесь и от документов :)

Ну низнаю что у вас тама за база такая.
Но.
Есть у мене база где работает порядка 100 пользователей.
По аналогии с вашей регистров нет.
Называется документооборот.
Так вот тама все пучком документы вносятся очень активно, но блокировок практически нет.
+ база под управлением SQL 2008 R2.
Все летает.
Единственное узкое место это стал Журнал регистрации, посему пришлось его перевести на SQL.
Да кстати может у вас как раз с этим и связано.
Потому как после перехода с 2000 на 2008 начали странные вещи твориться.
1.Туго открывались формы.
А в пике нагрузки на базу инфо в журнал регистрации вообще отказывала записываться.
Вот я грешным образом и заподозрил ЖР.

(117) он же написал файловая.

(111) Опишите полностью Ваш сервер.
Особенно интересует дисковая система
какие диски, есть или нет раид
какое распределение по дискам операц системы и приложений.

Также померьте скорость обращения к диску где база и длину очереди к этому диску.

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



30 пользователей в терминале должна и dbf и dql версия хорошо работать.
Может быть осталось несколько человек кто подключен не через терминал
а если у них еще и плохая сеть то будете иметь то что написано в subj.


>>>регистры не используются
так может у тебя бух счета используются.


Также что у Вас за текст программы в модуле(ях) проведения

Например если написать в модуле проведения
    Вопрос("сохранять заявку","Да+Нет");
это сведет на нет любой суперсервер и симптомы будут такие как в 0.
как бы можешь выложить md  и как бы после такого длительного обсуждения
тебе укажут на явные косяки твоей конфигурации.

(110) Я против сказок о 20-кратном приросте от прямых запросов.

(109) Информацию по справочнику можно кешировать средствами 1С, и не вызывать дважды функцию по одному и тому-же элементу, а перед вызовом искать в кеше.

(116) Не знаю тоже что там у них, но когда-то занимался базой со 100 пользователями, регистры там были... и много
...и обмены, и загрузки из других баз, и роботы... и робот как-то успевал допроводить 2-3 заявки в секунду
Все сам писал... не совсем оптимально, но было мало времени...

(120) Ну и напрасно...
Вот, например, цитата из внедрения: "В результате проведенной оптимизации справочник, состоящий из почти 5000 позиций,  обновляется в среднем за 2.7 сек. (время заполнения до оптимизации – 62. 4 сек.)"

(109) Может пора на олап-кубы? Накуя вменяемому человеку больше 5 группировок по 100500 строк?

(123) Где сравнение с оптимизацией на встроенном языке?
уже же отвечал на подобные некорректные сравнения.

(125) Оно и было на встроенном
Да, каюсь, можно было штатно использовать транзакции пачками
Но бывают чистые проигрыши, в десятки раз... тут очень много нюансов (структура данных, кривость штатных механизмов и проч.)

(126) что значит "было на встроенном"?
ты провел оптимизацию неоптимизированного кода. получил прирост скорости.
Простой вопрос - каков был бы прирост скорости от оптимизации на встроенном языке?
нафига сравнивать неоптимизирлванный код на встроенном языке с оптимизированным с использованием нештатных методов?
Сравнивают оптимизированный код с оптимизированным.

(120) Элементарно.
Вводиться свой индекс и прямой запрос 1с++ по этому индексу может быть и в 20 и в 100 раз лучше чем
Запрос_1с = СоздатьОбъект("Запрос");
все зависит в этом случае от качества это индекса.

(128) кто мешает ввести индекс штатными методами? Просто поставив галку на нужных измерениях регистра, и сделав правильный порядок измерений для нормального использования сквозного индекса?

(121) Так при этом ты кешируешь все атрибуты справочника а их может быть много, а с помошью прямого запроса ты кешируешь только нужные аттрибуты.

(130) что?
в справочнике как правило отражается инфстрока. Так её и кешируешь. если в форме списка выводятся некие показатели в многострочной части, то кешируешь и их. зачем кешировать лишнее?

(129) Мешает 1с.не знаю додели в v8 или нет.
Расскажи как ввести составной индекс по двум полям
шапки документа штатным способом и как по такому индексу сделать запрос штатным способом ?

(131) как что
есть раника кешировать 50 атрибутов справочника ( при этом могут в качестве аттрибутов выступать и длинные фиксированные строки ) или 3 атрибута нужные именно в этот момент.

об этом давным давно есть моя статья на 1с++

(132) Что-то НС совсем занудный стал, стареет...

(133) Ты видимо не понял мой вопрос. Почему я штатными средствами должен кешировать ненужные реквизиты? это игра такая?
(132) повторюсь - правильно использовать сквозной индекс.

+ (135) Чтоб было понятней, о чем идет речь.
Выше говорилось о тормозах при подборе по справочнику(но тоже самое в любой многострочной части, например в журнале).
Делаем кеш вычисляемых значений. Если в нем будет накапливаться не очень много данных, то например на ТЗ, если много, то на чем-нибудь индексированном, например штатный Xbase с индексами.
Функция СформироватьОстатки()  
    перем ИнфОстатки;
    ИнфОстатки="";
    ТекНоменклатура = ТекущийЭлемент();  
    Если пустоезначение(текноменклатура)=1 тогда
        возврат "";
    Конецесли;    
    стр="";
    Если ТЗОстатков.НайтиЗначение(ТекНоменклатура,стр,"Ном")=1 тогда
        ТЗОстатков.ПолучитьстрокуПОНомеру(стр);
        ИнФОстатки=ТЗОстатков.текст;
        Если ТЗОстатков.Цвет=1 тогда
            Форма.ТекстОстатки.Цвет(255);
        иначе
            Форма.ТекстОстатки.Цвет(0,0,128);
        конецесли;    
        Возврат ИнфОстатки;
    КонецЕсли;
        ...
        ТЗОстатков.Новаястрока();
    ТЗОстатков.Ном=ТекНоменклатура;
    ТЗОстатков.Цвет=Цвет;
    ТЗОстатков.Текст=Инфостатки;  
    Возврат ИнфОстатки;
...
И кто тут заставляет кешировать лишнее?

(133) не знаю может и не понял.
Как я это понимаю
когда 1с кеширует элемент справочника 1с кеширует все аттрибуты справочника при этом идет запрос к бд


select * from sc31 (nolock) where id = конкретноеЗначение.


Как бы моя идея заменять этот запрос с помощью 1с++ на

select Атриб1,Атриб2б Атриб3 from sc31 (nolock) where id = конкретноеЗначение.

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

ну 132 ты совсем не понял
на уровне штатных средст в 1с77 нет средсв построения индекса и использования этого индекса в дальнейших запросах

(136)
строка
ТекНоменклатура = ТекущийЭлемент();
уже временно кеширует много лишнего выполняя
select * from sc31 (nolock) where id = конкретноеЗначение.

(137) Точно не понял.
Речь шла о многократном получении атрибутов одного и того-же элемента справочника при открытой форме списка.

(138) Эта строка выполняется за одну миллионную долю секунды.
Для теста - замер производительности, 214 исполнений, 0.0002 секунды.
Вопрос - стоило ли переписывать нештатными методами, если легко штатными мы получаем моментальное выполнение?

(139) как бы ты можешь же кэшировать данные одного справочника в форме другого. вот тогда и будет выигрыш от 137.

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

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

(141) Не считаю злом. И не считаю что никогда не нужно использовать. Но то что выше приводилось как пример когда он нужен легко решается вышеприведенным кодом. И в третий раз пишу, то что нештатные методы дают 20-кратное ускорение - сказки.

А в данном случае - у тебя будет отзывчивость и скорость работы с любым справочником с таким кешированием - ровно такая-же как и с использованием 1С++.

(142) С модулями проведения такая-же история. Сравнивают как правило кривой код на встроенном языке, с оптимизированным нештатными методами. Оптимизировать же можно и штатно, и разница в скорости при этом по сравнению с нешататными получается символическая.

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

(143) Не всегда символическая, вот же упертый, 100500 раз было и после штатных попыток
То что штатные методы часто просто не могут использовать всех возможностей сервера забыл?

(144)
>>>И в третий раз пишу, то что нештатные методы дают 20->>>кратное ускорение - сказки.


Приходные накладные. В нем есть поле ДатаСЧФ.
отклонение датынакладной от датысчф может доходить до 10 месяцев.

конкретнаяя задача :
сформировать отсортированный реестр накладных по дате счетфактуры


создаем   по этому полю  sql индекс
получим запрос в 100 раз более эфективнSй 1С++ запрос чем перебор прихдокументов с многократным превышением диапозона дат прих накладных.


как бы эфективного решения этой задачи средствами 1с 77 - нет. Если скажите что можно сделать отбор по этому полю ну это не серьезно сравнивать индекс по таблице
с доп таблицей _1сsrdoc и сложный индексе  в ней.

ps 146 для 143

(146) Почему-же? можно и нужно сравнивать именно графу отбора.
если уж скорость критична - то можно тупо создать регистр с пустым ресурсом, и использовать индекс.

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

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

Доп регистр это еще и доп время на проведение этого документа и доп задержка блокировки -1sjourn.
(как бы пустой регистр это конечно хорошо но внутри он такой же тяжелый создает все равно курсор )
т.е. решение 146 эфективней чем решения предложенные в 148
по многим показателям.

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

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

ps к 150 также задача 146 была поставлена мне задним числом когда уже были документы за пять лет назад и как бы сделать ее
через 148 очень было бы затруднительно по сравнению со 146.

Вот как бы и имееем эфективность и другую затрат моего времени
более чем во 100 раз ( если сравнить 146 и 148 )

также имеем и эфективность ( во сколько раз оценивать не хочу
зависит от базы ) во времени исполнения запроса
одно дело seek индекса таблицы

другое дело соеденение (inner join ) двух таблиц.

(150) Одно движение по одному регистру с одним измерением - это не доп. время. Разницу в скорости никто и никогда не заметит.

(152) Так это разовая задача? Тогда индекс тут явно не нужен.

(151) что то ты переходишь с проблемы эфектифности 1с++
к проблеме работодателя иметь или не иметь хорошего программиста.

(151) Найти разработчика со знанием прямых запросов (фактически sql) намного проще, чем разработчика, который понимает как работают стандартные "черные запросы") Ибо sql-индустриальный стандарт..

(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 юзверейгенерят трафик и нагрузку гораздо меньше...