Перенес базу из DBF в SQL, одни и те же отчёты стали работать медленнее до 8 раз по времени, 19 сек, против 157 сек.
Пошерстил по интеру нашел вот это: http://catalog.mista.ru/public/82018/?detail=Y
всё выполнил.
Шерстил этот форум, проблема есть, решений нигде не нашел.

База весит 4Гб, планировал загружать товары от поставщиков по 200-300тыс наименований, для выгрузки в инт. магазин, поэтому заведемо перешел на SQL.

Конфиг:
Софт
Win Serv 2008R2 + Сервер терминалов
MSSQL 2008 R2. Режимы совместимости пробовал все 2000/2005/2008
1С 7.7 v27 Секретный релиз

Xeon E5-1650v4 6*3,6-4,2GHz
16Gb 2400 DDR4 ECC
SSD 200Gb Intel S3710 (один из топовых)

Задача №1 ускорить работу, №2 расширить базу до объёмов 20ГБ++

Вопрос: мне пытаться дальше мучать 1С 7.7 чтобы она заработала быстро на SQL, или это мертвая тема?

(56) А что 24 часа, а что не 36 или 48?

А нас нормальный рабочий день с 9 до 18 + 1 час обеденный перерыв
Никто 24 часа в сутки не сидит не бъет.
В пике (если смотреть по ЖР) по 3-4 документа в секунду проводят

(57) А я разве где то написал что 8000 реализаций?

есть заявки, есть приходы, есть реализации и касса, есть еще куча более мелких документов (например документ рейс, или отчет водителя по рейсу)

(60) я щяз заплачу ... каких еще у вас там есть документов, которые ну вообще от словам СОВСЕМ не влияют на производительность системы?

(50) Полностью согласен! Переписать что написано годами на 8?
Нужен штат программистов, а главное время на отладку. А если сеть магазинов там работа встанет.

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

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

Более того какая нагрузка на систему когда менежджер сидит в подборе? никакой

А вот когда на основании отчета водителя системе нужно сформировать 250 приходников по кассю... или сформировать одновременно 80 фактур... вот тогда и понимаешь на сколько важна скорость записи и что средняя температура по больнице тут никак не канает, потому что машина не будет ждать до 20 вечера, если она должна в 15 часов уехать

Если все расчеты на прямых запросах, то собственно запись 10 строк в 1С доли сек штатно занимает в один регистр

ну проблема с общим журналом для всех документов имеет место быть

(56) А если база распределенная и документы прилетают из других баз?
Все реально.

(66) ну только так. и никак иначе. но это нечестно :)

(62) и изучить и переписать ВСЕ на прямые запросы быстрее?
Все отчеты, подборы, документы, которые "писались годами" и "прекрасно" работали на dbf на скуле работать будут с большим скрипом.
И тут вопрос что лучше писать с 0 на прямых запросах но на 7-ке или писать с нуля но на 8-ке. Какой вариант более перспективным?
Более того в случае с 8-кой у тебя хоть сообщество есть у которого спросить можно, какого хрена оно тормозит и что покрутить. А в случае прямых запросов ты где найдешь мамонтов, которые согласны за спасибо все грабли рассказать?

(68) ну. так ты перешел на 8ку?

(69) меня и дбф устраивает. Сейчас вот нашел косяк со модом, переделал кое что и всё хорошо.

(68)
За 8 ку больше платят и работы больше, интереснее, карьеры больше
так что выбор очевиден

(66) нет как раз в этом году последний филиал пересадили в единную базу
До этого (лет 10 назад) пытались создать единную базу на скуле куда стекаются все данные, но тупо по времени не успевала обмены проходить.
Ушли на мод с выборочными обменами (НСИ + межфилиальные перемещения). А елинную базу создали на 8-ки

(65) все запросы штатные. Я прикручивал логи на модули проведения, там действительно все проводится за доли секунды. Вот если кто то задним числом пытается провести, то там да расчеты 10-15 секунд занимать. Но для нас работа задним числом больше нонсенс чем практика. Любыые изменения через документ (вычерки, клиент что-то не принял - возврат текущим числом, а ПФ уже учитывают структуру подчиненности и автоматом печатают за вычетом. Правка заявок - через ввод на основании и корректировка новой)

(72) Штатными средствами распределенных ИБ сложно (если много баз не реально по времени).
У меня текстовыми файлами все летит на сервер и обратно через почту.

(0) если вопрос в только "планировал загружать товары от поставщиков по 200-300тыс наименований" дак пиши в базу сразу и выборку делай для выгрузки тоже от туда

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

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

(76) Конечно все зависит чем базу нагружают отчетом, проведением документов или еще чем. Ведется запись или считывание информации? Исходя из этого и нужно копать.
(0) Скуль тупит по всему - я не верю.

(75)  у меня тоже есть аналогичный справочник, куда я гружу прайсы поставщика (с ценами количеством).
При этом менеджер имеет возможность принимать заявки по этому справочнику (где он видит индивидуальные цены клиентов), автоматом загружаются фото при наличии (при загрузки тащатся с сайта поставщика)
Короче при количество элементов порядка 630 тысяч элементов дбф имеет размер в 450 метров.
Т.е. для дбф 200-300 тысяч это семечки по размеру. Т.е. будет порядка 200-300 мб.

(54) А я и не говорил что у меня все без ВК. Я говорил про модули проведения и расчета.
Например у меня есть отчет который показывает текущую загрузку машины (в рублях, кг, в клиентах и т.п.) и в сравнении в средней за последние 3 месяца. Естественно я не считаю каждый раз данные за последние 3 месяца а храню их в SQlite таблицах. Т.е. к проведению и расчетам это никак не относится. Можно конечно зависит справочник и в 7-ке и хранить там, но я решил хранить во внешних таблицах
Еще на Sqlite у меня логи изменения документов (т.е. кто когда и что поменял в документах/справочниках)

Из 1С++ я юзаю ИТЗ ибо группировки для отчета проще формировать методом сгруппировать. Но опять таки это для внешних отчетов

Еще в некоторых отчетах Йоксель, чтобы "плюсики как в 8-ке"
Ну и Сканер, ФР - это тоже ВК

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

(49) 40 активных на ТИПОВОЙ SQL-2000  версии бухии

(51) Подожди, еще пара десятков постов и тебе начнут доказывать, что гибкие блокировки не нужны, и вообще покупатели у тебя ненастоящие :))))

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

(83) С бухучетом и так проблем особых нет, на sql он хорошо работает через бухгалтерские запросы.

(84) не ври.. переписывал для московской страховой под прямые

(84) Настолько "замечательно", что если стоит вопрос бух.учет переводить с dbf на sql или резать базу, режут базу.

(84) ага да типовая ОСВ по 41 счету в базе упрощенка с 30 юрлицами за месяц формировалась 10-15 минут. с той скл 15 -20 сек

(85) Ну не знаю. У нас одно время была семерочная база с 8 миллионами проводок - на sql отлично крутилась.

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

Если вернуться к вопросу топикстартера - что-то у него в самопальной базе не хОчет крутиться внутри сиквела, а ему об этом так никто и не сказал.

(0) 4 гб в дбф это база ни о чем, можно было и не переводить

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

(90) // Задача №1 ускорить работу, №2 расширить базу до объёмов 20ГБ++

(92) Ну для начала, нужно было решить задача №0 - уменьшить размер базы в 2-5 раз. Уверен, там мусора больше, чем половина. И тогда, мот и на скуль не надо совсем.

(44) писал я, самописная конфа у меня, не дал её один программер в 2006г когда я начинал бищнес, она была корявая и недописанная, но когда я это понял уже было не до перехода в другую.

(88) фигня какая, у меня на дбф крутилась база с под 16 млн проводов, норм.
Когда перестала влазить - года 4 назад купили скальный вариант

(93) угу. И регистров незакрытых. Поэтому и тормозит.

Тс для начала ужми базу на ИС обработка
Шишки для мартышки

(94) размер самого большого дбф файла огласите и его имя..ну и следующих пару в этом "рейтинге"

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

(94) я не против, а точнее, по топику еще догадался, что конфиг этот будет или полностью самописным или сильно переделанным и не похожим на типовые. Поэтому столь увлекательное обсуждение в этой ветке Вас может развлечь, но мало чем помочь. Надо смотреть саму базу - конфигурацию/структуру. Вот в (98) вопрос уже задан:

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

Конфу то озвучили?

(101) проснулись? всю ветку читали?

(99) не, тупо читает через метаданные регистры

На дбф все было хорошо кроме двух существенных - 1)слетали индексы 2) Так и не реализовали динамический список на прямых

(63) 10 часов народ начинает потихоньку заходить в базу
https://b.radikal.ru/b03/1801/56/cf32ceeaf44c.png

Я кстати пропарсил ЖР за прошлый понедельник. Всего уникальных сессий 140. Т.е. это теоретический максимум.

(21) "почему одно и то же работает с такой разницей в скорости на разных типах БД" - так работает движок, смирись. Или переписывай.

12 часов - 118 подключений и 2400 документов

(0) 1C++ может ускорить работу до 100(ста) раз. Проверено. Не во всех местах, но, если покопаться, эффекта добиться можно.

(107) Очень круто. Режете раз в год или чаще?

у нас 70 магазинов. примерно 500 000 клиентов в справочнике.  Режем каждый год.

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

(98) 500Мб документы расхода РН
и ещё с десяток по 430-480Мб, не смотрел что там.
Но мне надо сотни тысяч товаров с описанием загружать, и по несколько раз на день их переоценивать документом.
Сейчас база, конечно, не большая, но я хочу сразу на вырост, решить задачу, чтобы потом сломя голову не думать, что делать?

(108) Это если слабо оптимизирована. При анормальной настройки индекса цифры будут на порядок выше. Избавление от периодических элементов и переделка регистра партий радикально ускоряет базу.

(110) А какой смысл резать базу, если она на SQL переписана? Сделайте сегментирование в СУБД, если места мало.

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

(108) благодаря чему? Это если переписать на прямые запросы?

(112) Зачем все хранить в базе?
Зачем их каждый день переоценивать

(115) благодаря http://www.1cpp.ru/docum/icpp/html/TurboBL.html просто "холостым" подключением ВК.
А прямые запросы не 100, а в 1000 могут ускорить.

(112) имя файла какое ?

(112) тебя в (98) спросилимвполне конкретно про имена самых больших файлов. Что ты здесь мургу невнятную гонишь? Не знаешь как ответить на поставленный вопрос - так и пиши: звиняйте, не квалифицирован, свнтезник я, поставили одинэсить, покажмте пальцем как размер файла посмотреть...

(0) //для выгрузки в инт. магазин,

в интернет магазин? Кассу уже подключили?

(120) А что не так с кассой? С июля бъем из 7-ки.
Сейчас вот еще 2 кассы по новой организации буду подключать

(121) вы и (0) это одно и тоже? Вы в три смены? ночью оплата проходит? Как чек выбивается?

(122) А ты в этом контексте
Нет разные люди, но наличие сайте не означает что будет оплата на сайте.

У нас, к примеру, сайт чисто для заявок, оплаты ночью не приходят.
Хз как у ТС

(123) ну вот а мне интересно, иначе зачем переходить на скуль. Что за интернет магазин на 300 тысяч номенклатуры это филиал алиэкспресс что ли?

(124) это лавочники типичные. которые торгуют ничем и одновременно всем.

(124) ну почему. В автозапчастях на отечественные машины это число легко превышает 500 тысяч. А если брать иномарки, то 5 лямов это не предел

Удобно. Собрал прайсы с поставщиков переоценил и вывесил на сайте. Потом успевай только переадрисовывать заказы поставщикам. Красота. Ни тебе нелеквидов, ни складских площадей

(127) именно так в середине 2000-ых работал по фармации-опту. на складе был минимальный запас. вся торговля шла "с колес". большие прайсы от поставщиков - компилировались - вывешивались как собственные. по заказам - шла мегаразброска и согласование. Я как-то уже здесь упоминал - по отдельным заказам клиентов - дерево подчиненности от заказа до отгрузок на 20-30 листов - это вообще было норма. ниче, справлялись... правда не 200-300 тыс.. наименований товара - много меньше, тыщ 15...

(128) Это как "с колес" - только целыми коробами торговали? Принимали на складе и сразу навешивали ярлыки с адресом клиента?
Не представляю логистику - это ж надо всю фуру поставщика быстро распродать, чтобы остатков не было!

(112) "но я хочу сразу на вырост" - абсолютно правильное желание, и оптимальный выход пока один - 1С 8. Фирма получит: масштабируемость, большое кол-во спецов. Да, тебя легко смогут заменить, но опыт внедрения сыграет свою роль в резюме, в отличие от SQL 7.7.

(129) Ну примерно так. У нас сразу при поступлении печатается бумажка по клиентам и направлениям. И при приходе они сразу раскладывают по коробкам по клиентам.

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

(129) нет. заказ на 100-200-300 строк. раскмидывался по куче поставщитиков с выбором предпочтнений по предоплате/отсрочке и прочео всего. По приходу поставоке - они принимались сразу как положено - в т.ч. с выбраковокой по фальсификатам и проочему и сразу шли в сортировку/набор по заказу/заказам (кросс-докинг) остаток шел на склад. фурами не приходили поставки - не тот масштаб. ;-)

(119) http://clip2net.com/s/3Pmdwar

(119) https://c2n.me/3RvU51G

(125) 20-30к рабочие позиции, остальные неактуальные для индексиции в поисковиках. Вон глянь сайт nix.ru у них с самого начала работы фирмы позиции хранятся в ИМ и фото к ним.

(127) Вот-вот, только ещё и переоценка должны быть автоматическая, некоторые сервисы сами собирают цены, за небольшую плату. По API можно забрать этот анализ и на основании него создвать док. переоценка.

В   шапке   документа 3237   поди  88 реквизитов с типом строка(1000) ?
:)

Ну и видно 4 незакрытых регистра

Ну и в целом, этой базе с таким размером еще лет 20 жить на дбф можно

особо не заморачиваясь

(138)реквизитов много, но типов значения "строка" с неограниченной длиной нет.
(139) Подробнее плиз, можно? Что значит незакрытый, как определить и как закрыть?
(140) (141) Ок, но скорость хотелось бы увеличить.

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

2. когда RG>RA одноименного регистра

(143)
2. А что понимается по "закрытием" регистра, есть какая ссылка или как вообще искать решение, каким запросом?

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

(117) Ну это у меня уже давно, я пользуюсь раскраской таблиц от 1c++ FormEx, так что эта компонента у меня подгружается при старте системы.

(145) Как такое возможно? Если это регистр остатков денег или остатков товаров, я же не могу заприходовать товар на одну фирму, у списать потом вообще не указав фирму... У меня будет остаток "0" пока я точно не укажу набор измерений с положительным остатком...
Ну или в отчётах без фильтров по измерениям должны будут вылазить "минуса" перекрываемые "плюсами".
Но ни того ни другого у меня нет.

(145) а если я измерение не указываю, например "подвид товара" т.к. ими не пользуюсь то и запись м него идёт пустая как при "Приходе" так и при "Расходе".

(148) покрути регистр, например, каким-нибудь RegPrint'ом.

(147)
приход
   фирма1 товар1 количество 10

расход
   пусто   товар1 количество 10

в RG будет 2 записи
период1  фирма1 товар1 количество 10
период1  пусто товар1 количество -10

и они будут переходить из периода в период

а в отчете останков по товару ты видишь 0.

ну и т.д.. Это тебе примитивный пример

(150) Ясно, ща закручу отчёт проверю.
А когда всё исправлю, что надо сделать чтобы файл уменьшился?

(150) Собсно нашел один регистр, с одним измерением, но у него ещё есть реквизит, так вот реквизит всегда разный во всех проводках. Из-за этого может быть незакрыт регистр?

(154) реквизит фигня

главное набор измерений

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