Продолжение: Справочник 110 000 элементов - кинте плиз пример ускорения работы с таким
Результаты теста:

***total***     604090.0     100.0
LCK_M_U     189734.0     31.4
NETWORKIO     189064.0     31.3
LCK_M_X     179376.0     29.7
LCK_M_IS     19175.0     3.2
CXPACKET     10164.0     1.7
PAGEIOLATCH_SH     6752.0     1.1

***total***     604090.0     100.0
LCK_M_U     189734.0     31.4
NETWORKIO     189064.0     31.3
LCK_M_X     179376.0     29.7
LCK_M_IS     19175.0     3.2
CXPACKET     10164.0     1.7
PAGEIOLATCH_SH     6752.0     1.1
PAGEIOLATCH_EX     3822.0     .6
WRITELOG     2845.0     .5
LCK_M_IX     1078.0     .2
LATCH_EX     845.0     .1
PAGELATCH_EX     419.0     .1
PAGELATCH_DT     .0     .0
PAGEIOLATCH_NL     .0     .0
PAGEIOLATCH_KP     .0     .0
LATCH_DT     .0     .0
PAGELATCH_NL     .0     .0
PAGELATCH_KP     .0     .0
PAGELATCH_SH     250.0     .0
PAGELATCH_UP     267.0     .0
PAGESUPP     16.0     .0
SHUTDOWN     .0     .0
CURSOR     .0     .0
EXECSYNC     .0     .0
LATCH_NL     .0     .0
LATCH_KP     .0     .0
LATCH_SH     .0     .0
LATCH_UP     .0     .0
PAGEIOLATCH_DT     .0     .0
TRAN_MARK_NL     .0     .0
TRAN_MARK_KP     .0     .0
TRAN_MARK_SH     .0     .0
TRAN_MARK_UP     .0     .0
TRAN_MARK_EX     .0     .0
TRAN_MARK_DT     .0     .0
PAGEIOLATCH_UP     31.0     .0
LCK_M_SIU     .0     .0
LCK_M_SIX     .0     .0
LCK_M_UIX     .0     .0
LCK_M_BU     .0     .0
LCK_M_RS_S     .0     .0
LCK_M_RS_U     .0     .0
LCK_M_RIn_NL     .0     .0
LCK_M_RIn_S     .0     .0
LCK_M_RIn_U     .0     .0
LCK_M_RIn_X     .0     .0
LCK_M_RX_S     .0     .0
LCK_M_RX_U     .0     .0
LCK_M_RX_X     .0     .0
IO_COMPLETION     251.0     .0
ASYNC_IO_COMPLETION     .0     .0
RESOURCE_SEMAPHORE     .0     .0
DTC     .0     .0
OLEDB     .0     .0
FAILPOINT     .0     .0
ASYNC_DISKPOOL_LOCK     .0     .0
UMS_THREAD     .0     .0
PIPELINE_INDEX_STAT     .0     .0
PIPELINE_LOG     .0     .0
PIPELINE_VLM     .0     .0
LOGBUFFER     .0     .0
PSS_CHILD     .0     .0
EXCHANGE     .0     .0
XCB     .0     .0
DBTABLE     .0     .0
EC     .0     .0
TEMPOBJ     .0     .0
XACTLOCKINFO     .0     .0
LOGMGR     .0     .0
CMEMTHREAD     .0     .0
LCK_M_IU     .0     .0
MISCELLANEOUS     .0     .0
LCK_M_SCH_S     .0     .0
LCK_M_SCH_M     .0     .0
LCK_M_S     .0     .0

в целом не так плохо, теперь лезем сюда http://msdn.microsoft.com/ru-ru/library/ms179984.aspx

31.4
Имеет место, когда задача ожидает получения блокировки на обновление. Матрицу совместимости блокировок
31.3
NETWORKIO - понял что сеть, но не нашел

LCK_M_X - тоже не понял

NETWORKIO     189064.0     31.3 - бей админов

(3) если я ничего не путаю, это как раз затык в сети из-за множества мелких запросов.

(5) А объяснить можешь - шо це?

И из-за чего оно происходит?

(5) а смысл то. Сеть же не персональня для 1С. мало что там еще может передаватся.

+9 люди то работают.

(8) ну представь когда ты с винта копируешь 1000 файлов общей массой 1 мег и 1 файл 1 мег. Скорость одна будет?

http://www.sql.ru/forum/actualthread.aspx?tid=223096

(9) Это сиквел ожидает от клиента окончания принятия данных. Либо клиент тормозит, либо сеть...
NETWORKIO    0x800    This waittype indicates that the SPID is waiting for the client application to fetch the data before the SPID can send more results to the client application.

LCK_M_U - 31.4
Имеет место, когда задача ожидает получения блокировки на обновление.
NETWORKIO - 31.3
Обращение к сети
LCK_M_X - 29.7
Имеет место, когда задача ожидает получения блокировки на монопольный доступ.

(13) ну епть, когда листают справочник и идет чертова туча запросов к серваку мелких то что тут гадать.

Значит таки оно. ладненько - буду писать новую версию справоника..

есть еще предположения7

+15 как очередь к дисковой сстеме образуется. Сеть то одна и для всех клиентов.
Кстати автор. А что там за сеть? что за хаб?

(17) Конкретно модель не скажу - значю что гигабит

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

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

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

(19) Т.е. вопрос и в том что у клиента проблемы с сетью?

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

кроме того учитывая, что работают в терминале, странное вот это:
NETWORKIO - вероятно цитриксу мало памяти и он юзает файл подкачки, или ЦП мало

(16) Проверить сетевку, загрузку сети. Убрать из протоколов трубы.
Протестировать еще раз.

(23) там только рдп - стандартный..

(24) Да сетевухи как бы сильно не напрягаются - отсилы 25, макс 50% когда сильно большие отчеты получают

(25) тем более, проверить терминалы на свободную физическую память и загрузку ЦП

(21) Судя по результатам, сервер не захлебывается... А вот на клиентах - проблемы. (в принципе, может даже на одном клиенте)

(26) возможны проблеммы например в свиче, или еще где

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

одно могу сказать точно - винты СУПЕР

(30) Не создает и не кэширует. Только "черные запросы" так поступают.

(31) :) в какую сторону?

(32) понятно

(33) менее 1% напрягают, норма примерно 10% по этому можно увеличить скорость SQL примерно в 5-10 раз

(33) в хорошую...
--
И посмотри степень параллеллизма. Если не 1, то поставь в 1.

(35) Круть, а как её увеличить? :)

(37) а смысл, если у тебя проблема на стороне клиента

(37) Нормальными запросами :-))))))

(37) если устранишь первые 3 строки

(39) Это понятно..
(40) Тоже понял, т.е. имхается мне справочник переделывать 100%

+(38) Кстати, да... Что же сказал старый еврей Профайлер? :-)))

(41) Справочник переделывать не так просто. тебе везде надо копать где реквизиты используются.
Для начала убери все эти запросы с формы и кешируй в ТЗ что выбиралось хоть раз. Как писалось ранее.

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

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

для начала:

1. напряги админов на предмет потеряных покетов на роутерах и постарася привести количество роутеров от сервера к клиенту не более 2х (правило 3-4-5, вторая часть)
2. проверь на всех клиентах ОЗУ

потом уже за справочник.

(45) дык у него же терминал помоему. там клиент то один фактически.

(46) не на 100% если у него 49 в терминале и один на дохлом клиенте то этот 1 и тормозит все

(46) терминальных машин 3 штуки

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

(48) 1с ОЧЕНЬ плохо с широковещательными пакетами ведет себя (особено когда разное количество сегментов), это то-же админам на ухо шепни

(48) В общем убирай все нафиг из формы.

ужас - на 1 серваке сотка!

(52) балансируй нагрузку

вечером обещали гигабит поставить :)

(52) Воттераз! подумал Штирлиц....
Вообще, пусть в каждый терминальник по две сетевки воткнут! Одна под клиентский доступ, вторая - под сервер БД

В общем, советов тебе хватит...

(55) ты думаешь там не так? Это вообще-то аксиота так сказать для профи терминальные серваки и СКл сервак посадить на отдельный гигабитный канал

аксиота = аксиома

(54) админов запинать

(57) аксиомы - они разные бывают :-))) Некоторым аксиомы доказывать приходится... (правда, после этого теоремам на слово верят :-))

так - т.е. сеть надо мутить - это раз. правильно?

(61) да у тебя там целый комплекс.

(61) Мутить не надо - она у тебя и так мутная :-)
Но в первую очередь разобраться именно с сетью. Как толлько нетворкио уменьшится до единиц процентов - можно будет смотреть далее

(63) короче опять все ждем завтра :) и новых результатов тестов

(64) а что. Это увлекательный процесс. Я сам берусь с удовольствие за работу по переводу на скл с дбф и оптимизацией дальнейшей. Увлекательно и не скучное тупое кодирование

В общем патч установлен, скуль вроде хавает 7 гигов, с/к заменена.
Короче завтра буду считать :)

Ну что? в общем видимых результатов данные действия не принесли - снова запустил счетчики..

(67) Спрошу в тысячный раз - "а что говорит товарищ Профайлер"?

(68) Куда тыкать в этот профайлер? шо це ваще?

DBCC SHOWCONTIG scanning '_1SCONST' table...
Table: '_1SCONST' (1640717989); index ID: 1, database ID: 8
TABLE level scan performed.
- Pages Scanned................................: 21637
- Extents Scanned..............................: 2720
- Extent Switches..............................: 2803
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 96.47% [2705:2804]
- Logical Scan Fragmentation ..................: 0.48%
- Extent Scan Fragmentation ...................: 19.74%
- Avg. Bytes Free per Page.....................: 1298.4
- Avg. Page Density (full).....................: 83.96%

+(69) уже разобрался..

(710 буду смотреть профпйлер

(70) судя по всему у тебя явные проблеммы с переодическими реквизитами

1. попробуй почистить конфу от лишних
2. можно подрезать историю (в разумных значениях)
3. сделать упаковку и реиндексацию средствами SQL (а также обновить планы запросов и сбросить статистику)

(73) обновить планы запросов и сбросить статистику - это какими методами?

(73)+ если в переодических есть строки - уменьши их длинну

(74) это средствами SQL... я не помню, ибо делают это админы

(73) "обновить планы запросов и сбросить статистику" - можно подробнее?
Точнее, зачем сбрасывать статистику, и как обновить планы запросов?

поспрошаю - но врядли они что-то толковое скажут..

(77) это SQL фишки связаные с оптимизацией запросов средствами SQL, делаеться это для того, что-бы сам процесс оптимизации запросов шел быстрее. подробнее  ищи в документации или www.sql.ru

DBCC INDEXDEFRAG(database_name, table_name, index_name).

(79) Сброс статистики обычно делается для оптимизации плана выполнения при существенном изменении структуры базы (например, добавления/удаления/изменения структуры индексов) - для того, чтобы старая статистика не влияла. Зачем сбрасывать при уменьшении количества данных - я не понимаю.
А планы запросов вообще строятся автоматически (если не указывать хинты, а 1с их не указывает) основываясь на статистике, поэтому этот пункт непонятен вообще...

4. Обновление статистики для оптимизации запросов:

exec sp_msforeachtable N’UPDATE STATISTICS ? WITH FULLSCAN’
DBCC FREEPROCCACHE

(c) Регламентные операции на уровне СУБД для MS SQL Server
Автор: Рупасов Константин (1С, Москва)

Для обновления статистик по всем таблицам базы данных необходимо выполнить следующий SQL запрос:
exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'

Таким образом, рекомендуется всегда после обновления статистик очищать содержимое процедурного КЭШа.
Для очистки процедурного КЭШа MS SQL Server необходимо выполнить следующий SQL запрос:
DBCC FREEPROCCACHE

Рекомендуется регулярное выполнение дефрагментации индексов. Для дефрагментации всех индексов всех таблиц базы данных необходимо использовать следующий SQL запрос (предварительно подставив имя базы):
sp_msforeachtable N'DBCC INDEXDEFRAG (<имя базы данных>, ''?'')'

Рекомендуется выполнять регулярную переиндексацию таблиц базы данных. Для реиндексации всех таблиц базы данных необходимо выполнить следующий SQL запрос:
sp_msforeachtable N'DBCC DBREINDEX (''?'')'

(81) при изменении конфигурации 1с это НЕ ДЕЛАЕТ, по этому это надо делать переодически... кроме того влияет размер таблиц, а они растут.

(84) Естественно, 1с это не делает. Только в данном случае затыки с периодикой, а эта табличка "условно-постоянная", из пофигурации ее не исковеркать. Поэтому статистика ее неизменна (условно, конечно) и зависит от данных (не столько от их количества, сколько от вариативности). Размер таблиц может играть существенную роль только при фуллскане, а тут все-таки индексный...

(80)
DECLARE @MyTable varchar(32)
DECLARE @MyIndex varchar(32)
DECLARE MyCursor CURSOR FOR
SELECT o.name, i.name
FROM sysobjects o INNER JOIN sysindexes i ON o.id = i.id
WHERE (o.xtype = 'U') AND (INDEXPROPERTY(i.id, i.name, 'isStatistics') = 0) AND (i.dpages > 0)
ORDER BY o.name, i.indid
OPEN MyCursor
FETCH NEXT FROM MyCursor INTO @MyTable, @MyIndex
WHILE @@FETCH_STATUS=0
BEGIN
PRINT 'Дефрагментация индекса '+@MyIndex+' из таблицы '+@MyTable
DBCC INDEXDEFRAG (0,@MyTable,@MyIndex)
FETCH NEXT FROM MyCursor INTO @MyTable, @MyIndex
END
CLOSE MyCursor
DEALLOCATE MyCursor

(85) LOL

признак сортировки у переодического реквизита убери, или вообще сделай из переодического постоянный реквизит

(87) Признак сортировки у периодического???? это как, пардон?
А если я сделаю постоянный, вариативность индекса idd не изменится.

(88) ну ступил с сортировкой.

все равно размер имеет значение :)

Не надоело? :)

(90) мы сейчас еще голосовалку заведем и до 1000 постов дотянем :)

(89) Значение имеет не столько размер, сколько нормальная организация.

тихо так тихо: а может размер сетевого пакета уменьшить?

***total***,1461065.0,100.0
CXPACKET,428035.0,29.3
LCK_M_X,314154.0,21.5
LCK_M_IS,271796.0,18.6
NETWORKIO,182777.0,12.5
PAGEIOLATCH_SH,88060.0,6.0
LCK_M_U,81030.0,5.5
LCK_M_S,41172.0,2.8
LATCH_EX,14172.0,1.0
PAGEIOLATCH_EX,14147.0,1.0
LCK_M_IX,10999.0,.8
WRITELOG,10323.0,.7
IO_COMPLETION,1074.0,.1
PAGELATCH_EX,1982.0,.1
PAGELATCH_DT,.0,.0
PAGEIOLATCH_NL,.0,.0
PAGEIOLATCH_KP,.0,.0
PAGEIOLATCH_UP,343.0,.0
LCK_M_IU,.0,.0
LATCH_DT,.0,.0
PAGELATCH_NL,.0,.0
PAGELATCH_KP,.0,.0
PAGELATCH_SH,188.0,.0
PAGELATCH_UP,659.0,.0
MISCELLANEOUS,.0,.0
LCK_M_SCH_S,.0,.0
LCK_M_SCH_M,.0,.0
PAGEIOLATCH_DT,.0,.0
TRAN_MARK_NL,.0,.0
TRAN_MARK_KP,.0,.0
TRAN_MARK_SH,.0,.0
TRAN_MARK_UP,.0,.0
TRAN_MARK_EX,.0,.0
TRAN_MARK_DT,.0,.0
ASYNC_IO_COMPLETION,.0,.0
RESOURCE_SEMAPHORE,.0,.0
DTC,.0,.0
OLEDB,.0,.0
FAILPOINT,.0,.0
ASYNC_DISKPOOL_LOCK,.0,.0
UMS_THREAD,.0,.0
PIPELINE_INDEX_STAT,.0,.0
PIPELINE_LOG,.0,.0
PIPELINE_VLM,.0,.0
LCK_M_SIU,.0,.0
LCK_M_SIX,.0,.0
LCK_M_UIX,.0,.0
LCK_M_BU,.0,.0
LCK_M_RS_S,.0,.0
LCK_M_RS_U,.0,.0
LCK_M_RIn_NL,.0,.0
LCK_M_RIn_S,.0,.0
LCK_M_RIn_U,.0,.0
LCK_M_RIn_X,.0,.0
LCK_M_RX_S,.0,.0
LCK_M_RX_U,.0,.0
LCK_M_RX_X,.0,.0
LOGBUFFER,.0,.0
PSS_CHILD,.0,.0
EXCHANGE,62.0,.0
XCB,.0,.0
DBTABLE,.0,.0
EC,.0,.0
TEMPOBJ,.0,.0
XACTLOCKINFO,.0,.0
LOGMGR,.0,.0
CMEMTHREAD,.0,.0
PAGESUPP,91.0,.0
SHUTDOWN,.0,.0
CURSOR,.0,.0
EXECSYNC,.0,.0
LATCH_NL,.0,.0
LATCH_KP,.0,.0
LATCH_SH,.0,.0
LATCH_UP,.0,.0

CXPACKET,428035.0,29.3
Имеет место при попытке синхронизации итератора обмена обработчика запросов. Можно попытаться снизить степень параллелизма, если конфликты такого типа становятся проблемой.

LCK_M_X,314154.0,21.5
Имеет место, когда задача ожидает получения блокировки на монопольный доступ. Матрицу совместимости блокировок см. в представлении sys.dm_tran_locks (Transact-SQL).

LCK_M_IS,271796.0,18.6
Имеет место, когда задача ожидает получения блокировки с намерением коллективного доступа (IS). Матрицу совместимости блокировок см. в представлении sys.dm_tran_locks (Transact-SQL).

Люди! Ау!

(93) max degree of parallelism

отключай нафиг параллелизм

(98) это где и как? на работающем можно?

100 сто

а вообще примерно на 15% лучше уже стало :)

(99) на работающем можно, ставь цыфру 1 туда

(99) можно. Ставь 1. Перезапуска не требует.

sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
sp_configure 'max degree of parallelism', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO

так?

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

имей в виду, что ты имеешь статистику по СЕРВЕРУ, может у тебя какие другие "хитрые" базы или репликации или джобы ?

(104) ага
И снова EXEC track_waitstats :-)))

(99) Ентерпрайз манагер, на сервере твоем правая кнопка мыши свойства.
закладка процессы.
поставить галку в разделе параллелеизм на 1 процесс

(105) LCK_M_X - разве не TabLock_x &

(106) не понял?

Зы - что делать то? может из-за параллелизма 1 постарадать производительность сервера в целом?

(109) кроме баз 1с чего еще есть на SQL сервере?

(109) нет. не постразат. у тебя много пользователей и много обращений и запростов. СКЛ пытается распаралелить по процам задачу что на мелких задачах приводит к тормозам.
Помоему так.

(110) нет

(109) Он у тебя явно больше, чем 1 - посмотри через sp_configure
когда включено 'show advanced options'

58 коннектов сейчас к базе

(113)
sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
sp_configure 'max degree of parallelism';
GO


так?

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

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

(116) можно поподробне?

кстати параметр сменился с 0 на 1

запустил тест

(116) ну я это и имел в виду

на часок.

сделано:

   
sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
sp_configure 'max degree of parallelism', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO

(117) В янедекс. Там статейка хорошая есть на этот счет.

(118) правильно!
0 - это максимум

запускай тест еще раз.

(121) для тебя главный показатель увеличения производительности - это уделичение WRITELOG

в начале у тебя было 0.5% норма 5-10

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

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

(124) Откуда цифра?
(125) Почему же? Как раз при листании справочника на сервер идет куча мелких простых запросов. Которые как раз сейчас и тормозились из-за попыток параллельного выполнения (что показал счетчик CXPACKET).
Но для полного решения нужно вниматочно смотреть на форму списка.
Ну, и в профайлер, конечно...

(127) блин, был бы под рукой профайлер - глянул бы туда само сабой

но это позже..

(128) Второй день талдычу об этом...

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

(131) Мне самому то жуть как интересно :)

(131) Да все это давно описано. И неоднократно. Просто не в одном месте...

Десять важнейших проблем производительности SQL Server 2005 для приложений хранилищ данных и отчетности

http://www.microsoft.com/rus/technet/prodtechnol/sql/bestpractice/dw_perf_top10.mspx

***total***,46133.0,100.0
LCK_M_IS,13623.0,29.5
PAGEIOLATCH_SH,11517.0,25.0
LCK_M_X,6751.0,14.6
NETWORKIO,6129.0,13.3
LCK_M_U,5374.0,11.6
PAGEIOLATCH_EX,1000.0,2.2
WRITELOG,929.0,2.0
PAGELATCH_EX,496.0,1.1
LCK_M_S,109.0,.2
PAGELATCH_UP,111.0,.2
PAGEIOLATCH_UP,62.0,.1
IO_COMPLETION,31.0,.1
ASYNC_IO_COMPLETION,.0,.0
RESOURCE_SEMAPHORE,.0,.0

(135) Уже лучше. Но НетворкИО опять слишком велик....

PAGEIOLATCH_SH
   
Имеет место, когда задача ожидает кратковременной блокировки буфера, находящегося в состоянии запроса ввода-вывода. Запрос на кратковременную блокировку производится в режиме общего доступа. Длительное время ожидания может указывать на проблемы с дисковой подсистемой.

(136) PAGEIOLATCH_SH - это с чем связанно?

я имею ввиду для 1с

(137) Т.е. подбираешься к ограничениям подсистемы в/в. Это нормально. По-идее, в нее и упрешься в конце концов

(140) хы хы хы.. успокоил :)

(137) а где расшифровку на русском берешь?

(139) Это не "для 1с", это сервер ждет, пока некэшированная информация прочитается в кэш с диска...

WRITELOG - 2% это уже вполне приемлимый показатель

PAGEIOLATCH_SH - можно сделать кластер файла базы (несколько файлов) на разных дисковых массивах, но это уже не такое простое дело...

но вообще уже можно приступать к оптимизации самой 1с, то-есть переписывать узкие места...

(143) см (2)
http://msdn.microsoft.com/ru-ru/library/ms179984.aspx

(145) Спасиба. А я все на англицком читал, опасался за точность перевода...
(144) Так у него райтлог - всего 2% А нетворкио- 13%

Вот скрипт по дефрагментации индексов, может пригодится.


SET NOCOUNT ON
DECLARE @tablename VARCHAR (128)
DECLARE @indexname VARCHAR (128)
DECLARE @execstr   VARCHAR (255)
DECLARE @objectid  INT
DECLARE @indexid   INT
DECLARE @frag      DECIMAL
DECLARE @maxfrag   DECIMAL

-- Decide on the maximum fragmentation to allow
SELECT @maxfrag = 10.0



-- Declare cursor
DECLARE tables CURSOR FOR
 
   SELECT so.name, si.name FROM sysindexes si
   INNER JOIN sysobjects so
   ON si.id = so.id
   WHERE si.indid=1
   AND OBJECTPROPERTY(so.id, 'IsMSShipped' ) = 0





IF OBJECT_ID('tempdb..#fraglist') IS NOT NULL
DROP TABLE #fraglist
-- Create the table
CREATE TABLE #fraglist (
  ObjectName CHAR (255),
  ObjectId INT,
  IndexName CHAR (255),
  IndexId INT,
  Lvl INT,
  CountPages INT,
  CountRows INT,
  MinRecSize INT,
  MaxRecSize INT,
  AvgRecSize INT,
  ForRecCount INT,
  Extents INT,
  ExtentSwitches INT,
  AvgFreeBytes INT,
  AvgPageDensity INT,
  ScanDensity DECIMAL,
  BestCount INT,
  ActualCount INT,
  LogicalFrag DECIMAL,
  ExtentFrag DECIMAL)





-- Open the cursor
OPEN tables

-- Loop through all the tables in the database
FETCH NEXT
  FROM tables
  INTO @tablename, @indexname

WHILE @@FETCH_STATUS = 0
BEGIN
-- Do the showcontig of all indexes of the table
  INSERT INTO #fraglist
  EXEC ('DBCC SHOWCONTIG (''' + @tablename + ''', ''' + @indexname + ''')
     WITH FAST, TABLERESULTS, NO_INFOMSGS')
  FETCH NEXT
     FROM tables
     INTO @tablename, @indexname
END



-- Close and deallocate the cursor
CLOSE tables
DEALLOCATE tables




-- Declare cursor for list of indexes to be defragged
DECLARE indexes CURSOR FOR
  SELECT ObjectName, ObjectId, IndexId, IndexName, LogicalFrag
  FROM #fraglist
  WHERE LogicalFrag >= @maxfrag


-- Open the cursor
OPEN indexes

-- loop through the indexes
FETCH NEXT
  FROM indexes
  INTO @tablename, @objectid, @indexid, @IndexName, @frag

WHILE @@FETCH_STATUS = 0
BEGIN
   IF  @frag< 30.0  
       BEGIN
           
           SELECT @execstr = 'DBCC INDEXDEFRAG (0, ' + RTRIM(@tablename) + ', ' + RTRIM(@indexname) + ')'
           EXEC (@execstr)

       PRINT RTRIM(CONVERT(varchar(20),(GETDATE() ))) + ', frag[' + RTRIM(CONVERT(varchar(15),@frag)) + '], EXEC ' + @execstr
       END
   ELSE
       BEGIN
           
           SELECT @execstr = 'DBCC DBREINDEX (['+RTRIM(@tablename) + '], [' + RTRIM(@indexname)+'], 0) WITH NO_INFOMSGS'
           EXEC (@execstr)
           PRINT RTRIM(CONVERT(varchar(20),(GETDATE() ))) + ', frag[' + RTRIM(CONVERT(varchar(15),@frag)) + '], EXEC ' + @execstr
       END

  FETCH NEXT
     FROM indexes
     INTO @tablename, @objectid, @indexid, @IndexName, @frag
END

-- Close and deallocate the cursor
CLOSE indexes
DEALLOCATE indexes

-- Delete the temporary table
DROP TABLE #fraglist
GO

(146) нетворкио- 13% это конечно не гуд, но приемлимо. Он только на 1 час запускал, по этому мог просто попасть на 5 минутное зависание одного клиента

(147) так мож все проиндексить сразу?

(149) дефрагментировать

(150) да

но за скрипт спасибо

Короче справочник прикручен - остатки получаются сверх тормознуто, видимо придется таки юзать 1с++

1. покажи как остатки получаешь (надеюсь у тебя нету колонки с остатками??? а только статусная строка)
2. и покажи структуру справочника (из DDS)

(154) колонка у него с остатками. иначе с чего бы форме тормозить.
Еще как вариант остатки идут на текущую дату, а ТА загнали вперед. Вот оно и рассчитывается

(154) Колонка с остатками есть - но это к сожалению надо
В тестовом примере я убрал её, т.е. был только новый справочник

(155) Остатки на ТА.

Люди, плиз - киньте ссылками на 1с++ - меня интересует просто создание списка

(157) Какого списка?

(158) табличное поле т.е.

(159) зачем тебе остатки показывать не весь товар?? на список?

(159)
http://www.rikcenter.ru/downloads.php?file=6
пример справочника на табличном поле. НЕ оптимизирован под большие объемы. Просто демка.

(160) я же говорю - даже список номенклатуры получается с тормозами

(161) ок. спасибо

Думаю взять и посмотреть табличное поле - в него просто при вызове "пихнуть" весь справочник и посмотреть на результат..

>>>Колонка с остатками есть - но это к сожалению надо

БРЕД, не надо это!!!

по чему это не надо:
1. в данном случае вычисляемые поля не имеют гарантию правомерности (они обновляются редко)
2. давайте разделять формы подбора с остатками и обычную
3. делай структуру ограничивающую количество показываемых остатков например от вхождения в группу с текущим, ведь по факту не нужно видеть ВСЕ остатки а только текущего и похожих.
4. а вообще довольно и статусной строки. сделай 2 варианта формы, с колонкой и без и пусть пользователи сами решают (в своих настройках) какой формой вользоваться быстрой/полной

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

(165) Друг, даже просто получение списка номенклатуры без доп. полей тормозит - фактъ

Зачем нужна колонка с остатками???

(166) Тормозит - тормозит :(
(168) см (167)

(167) как проверял?

(170)+1

мне тоже интересно от куда такая информация

(170) сделал новый справочник, оттуда все убрал кроме списка номенклатуры
уже лучше - но все равно медленно
(168)

Объясняю почему нужны остатки:
Когда ищут например позицию выключатель такой-то
Артикулы у выключателей отличаются на последнюю букву - цифры.
Они идут рядом
Порядка от 10 до 100 одних и тех же зап. частей но с разными хар-ками.
Клиенту очень часто по барабану - выключатель может быть на параметр больше, например ток предельный на 1-2 ампера больше.

Я имеюю ввиду вообще новый справочник - туда тупо все перелил..

(172) А зачем выбирать товар в документ, открывая справочник?

(174) Обычно клиент звонит не просто так - у него на руках список из 100-200 позиций.
Ему нужно их где то купить..

Соот-нно основная рабочая форма это как раз форма этого справочника - менеджеры проводят в нём большинство своего рабочего времени

(173) структуру этого нового справочника покажи

щас

(175) Еще раз - зачем для выбора товара в документ открывать форму списка справочника?

#
#===============================================================================
#==TABLE no 240    : Справочник БыстраяНоменклатура
# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=SC20197 |Справочник БыстраяНоменклатура|A          |SC20197    |1        
#-----Fields-------
# Name      |Descr               |Type|Length|Precision
F=ID        |ID object           |C   |9     |0        
F=PARENTID  |ID parent obj       |C   |9     |0        
F=CODE      |object code         |C   |7     |0        
F=DESCR     |object description  |C   |25    |0        
F=ISFOLDER  |Flag - Is Line - Fol|N   |1     |0        
F=ISMARK    |Flag Object is Marke|C   |1     |0        
F=VERSTAMP  |Version stamp       |C   |6     |0        
F=SP20201   |(P)НоменклатурныйНом|C   |50    |0        
F=SP20202   |(P)ПолноеНаименовани|C   |100   |0        
F=SP20203   |(P)Номенклатура     |C   |9     |0        
#----Indexes------
# Name     |Descr         |Unique|Indexed fields                                              |DBName    
I=IDD      |of ID         |0     |ID                                                          |IDD        
I=PCODE    |of PARENT and |0     |PARENTID,ISFOLDER,CODE(UPPER)                               |PCODE      
I=PDESCR   |of PARENT and |0     |PARENTID,ISFOLDER,DESCR(UPPER)                              |PDESCR    
I=CODE     |of CODE       |0     |CODE(UPPER)                                                 |CODE      
I=DESCR    |of DESCR      |0     |DESCR(UPPER)                                                |DESCR      
#
#===============================================================================
#==TABLE no 241    : Справочник НоменклатураБыстр
# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=SC20204 |Справочник НоменклатураБыстр  |A          |SC20204    |1        
#-----Fields-------
# Name      |Descr               |Type|Length|Precision
F=ID        |ID object           |C   |9     |0        
F=PARENTID  |ID parent obj       |C   |9     |0        
F=CODE      |object code         |C   |7     |0        
F=DESCR     |object description  |C   |100   |0        
F=ISFOLDER  |Flag - Is Line - Fol|N   |1     |0        
F=ISMARK    |Flag Object is Marke|C   |1     |0        
F=VERSTAMP  |Version stamp       |C   |6     |0        
F=SP20222   |(P)ЕдиницаПоУмолчани|C   |9     |0        
F=SP20237   |(P)НоменклатурныйНом|C   |50    |0        
F=SP20261   |(P)Производитель    |C   |9     |0        
F=SP20265   |(P)ТипТовара        |C   |9     |0        
F=SP20280   |(P)НоменклатурныйНом|C   |50    |0        
F=SP20307   |(P)Ном              |C   |9     |0        
#----Indexes------
# Name     |Descr         |Unique|Indexed fields                                              |DBName    
I=IDD      |of ID         |0     |ID                                                          |IDD        
I=PCODE    |of PARENT and |0     |PARENTID,ISFOLDER,CODE(UPPER)                               |PCODE      
I=PDESCR   |of PARENT and |0     |PARENTID,ISFOLDER,DESCR(UPPER)                              |PDESCR    
I=CODE     |of CODE       |0     |CODE(UPPER)                                                 |CODE      
I=DESCR    |of DESCR      |0     |DESCR(UPPER)                                                |DESCR      
I=VI20237  |VI20237       |0     |SP20237(UPPER=128)                                          |VI20237    
I=VIP20237 |VIP20237      |0     |PARENTID,ISFOLDER,SP20237(UPPER=128)                        |VIP20237  
I=VI20261  |VI20261       |0     |SP20261,DESCR(UPPER)                                        |VI20261    
I=VIP20261 |VIP20261      |0     |PARENTID,ISFOLDER,SP20261,DESCR(UPPER)                      |VIP20261  
I=VI20280  |VI20280       |0     |SP20280(UPPER=128),DESCR(UPPER)                             |VI20280    
I=VIP20280 |VIP20280      |0     |PARENTID,ISFOLDER,SP20280(UPPER=128),DESCR(UPPER)

(175) а зачем на экран выводить остатки в таблицу? если интерисует аналог соседний манагеру трудно что-ли поставить на него курсор и посмотреть остаток в строке?

(178) Звонит клиент, ему нужно что-то купить!!!!
Иногда он даже не знает как точно это называется и какой у него артикул.

менеджер всегда открывает счет!!!! (т.к. люди обычно звонят с серъезными намерениями)
И набивает то чт о набрали в этот счет!

(180) ты пойми - их там может быть около сотни - этих аналогов

на каждый ставить курсор не очень удобно

Одних только кресел для водителя порядка несколько десятков - синие, зеленые, красные, бадовые, с ручками, без ручек, новой модификации - старой.
В 8 - ке это еще понятно - там есть свойства и харак-ки..
а в 7-ке это все отдельной строкой

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

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

Но зачм вы про остатки:
Я же говорю - даже список БЕЗ остатков тормозит

(181) Эх... Мне еще раз спросить?
Посмотри в ссылке из (161) обработку "Тест поля выбора a la 8.хх"

Быстрее правда работает - но все равно тормозит

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

(188) качнул, смотрю.

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

(190) Ну вот блин так - сам расстроен

Хотя еще попробую прийти сегодня после обеда и сделать кое что -

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

(194) Повторяюсь:
Есть список практически одинаковых товаров но с модификациями

их от 5 до 200. в среднем порядка 20-30

ок или не ок?

(195) Так и выводи этот список при наборе буковок. И показывай остатки по ним. Или показывай только те позиции, которые есть на остатках.

+(198) Не вижу проблемы.

(199) Есть еще 1 штука - есть 2 тз на форме - которые показывают:
1) от кого пришел товар и за какюу цену
2) кому ушел товар и за какую цену

благодаря этим полям магер еще делает красивую наценку именно для этого клиента

(200) А вот это уточнение стоило привести еще начале преддыдущей ветки.

(201) ну ссори если что не так. Но эти поля рассчитываются очень красиво и быстро - не тормозит практически

(200) что еще сть на форме?? может еще партии показывает все какие в наличии и кому какие пошли?

(203) нет, щас код покажу

(179)

Справочник.БыстраяНоменклатура

сделай
наименование, код, артикул, и ссылку на справочник номенклатуры

ИОП!!!!

ПокупкиИПродажи = СоздатьОбъект("Периодический");
   ПокупкиИПродажи.ИспользоватьОбъект("ПокупкиИПродажи", Номенклатура);
   ПокупкиИПродажи.ОбратныйПорядок(1);
   ПокупкиИПродажи.ВыбратьЗначения(,); // Граница);

Простите меня люди добрые - вот же в чм ж косяк ж еще

(208) тебе говорили, что блокировки это периодики выбор.

(207) Приколист ты... :)

ПокупкиИПродажи - это преодический рекв. справочника номенклатура, которые еще и документами изменяется..

(210) это не я..

(211) Ты-ты :)
Я имел ввиду сокрытие информации в течении нескольких дней :)

Т.е. насколкьо я понял из-за этого еще и тормозит. ееп..

(212) блин, ссори - просто не придал этому должного значения

(214) чудес не бывает. Все давно пройдено и грабли известны. их 2 всего. Вложенные реквизиты и выборка периодики. ;))

такс , т.е. насколкьо я понял - еще и придется переделать эту часть

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

DGorgoN - теперь с тебя развернутая статья по итогом 3х дней работ, по оптимизации SQL

(218) без б. сделаю, на почту кину тебе что-бы проверил, ок?

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

Первая версия:
/* Сделано через жопу. Прошу прощения у того, кто будет дорабатывать — меня заставили сделать именно так. */

Исправленная версия:
/* Cобрался с силами и исправил код так, чтобы он выглядел более логичным и читаемым. Концептуально он остался жопой, но теперь стал больше похож на аппетитную женскую попку, чем на суровую мужицкую задницу. */

Комментирование — занятие крайне интересное и творческое. Сделайте немного интереснее жизнь человеку, которому придётся потом разбираться в вашем коде!"

(219) И первые слова в статье должны звучать примерно так: "Самая главная мысль, которую я вынес из этой эпопеи - всегде (слышите, всегда!) сразу выдавайте полную информацию!" :)

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

(219) лучше садовникову - он лучше меня в этом разбирается

(221) Сам не обратил на это внимания, друг - прокололся немного. спасибо за пинки в нужном
(222) да вот уже думаю как бы оргаизовать то все - сегодня на обед съезжу, посомтрю..

(223) ок
(221)
Слушай, но ведь эти тз расчитываются именно в форме - это имет какое то значение?

т.е. переодика перебирается толкьо в форме.
В обед поеду - проверю..

(226) Так форма и тормозит у тебя, правильно? Сильно подозреваю, что код из (207) выполняется при каждом чихе на форме. Это же код из формы списка справочника, я ничего не путаю?

(227) и его в отладчике не видно. он же только модуль смотрит. В чем и всегда засада. Понатыкают на форму кода а потом хрен найдешь что тормозит

(227) Да. этот код из формы списка справочника.

(228) вот такие вот грабли :)

думаю что-бы сделать что-бы это рассчитывалось по кнопке

так-же можно сделать?

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

(233) ок

ту DGorgoN, поясни что за тест как эти показатели посмотреть. Откройте глаза мне.

ой, нашел сам вопрос снимаю спасибо

А меня всегда беслио когда 1сник в 1с77 хранить опер инфу в периодике. Ужас.

(237) Более того - этой переодикой вся конфа объята

(221) Цитата:
(219) И первые слова в статье должны звучать примерно так: "Самая главная мысль, которую я вынес из этой эпопеи - всегде (слышите, всегда!) сразу выдавайте полную информацию!" :)
=====
А вторая и третья фраза - "Ищите проблему в своем коде 1С, а уж потом начинайте копать сервер, железо и т.д." и "Попробуйте упростить свой код, свои запросы по максимуму, и только потом, если тормоза остались, тестируйте настройки базы, железа, сети и т.д."
.
ЗЫ у меня также пару месяцев назад была большая проблема на скульной 1С 8-ке - народ жаловался, что форма подбора очень сильно тормозит.
Начал разбираться, увидел жутко неоптимальный код прежнего программера :(, исправил его, но улучшение производительности произошло всего на 30-45%, что было недостаточно.
Увидел, что тормозит простейший запрос к группе товаров с выборкой из Спр.Товаров + Лев.Соед. по остаткам + Лев.соед.по цене товаров. Выборка цены - основной виновник.
Далее покопался в базе, добавил индексов и т.д., особого улучшения не заметил.
Перерыл всю 1С, улучшения не получил.
После этого 2 дня убил на настройку скуля, чтение доки, профайлер и т.д. - ничего не помогло.
Снова вернулся к 1С, к настройкам регистра сведений цены, начал экспериментировать с настройками этого регистра в 1С.
И о чудо, одна настройка помогла - пред.разработчик поставил периодичность хранения итогов цены по регистратору, а я поставил по дням. 1С просто залетала, ускорение порядка 200/300% :)

Т.е. причина, как обычно, в собственной настройке 1С, а скуль и железо, как обычно, не виноваты :)

(239) +1000
как показывает практика даже дефолтных настроек скуля, винды и железа вполне достаточно

(240) SQL - да, по дефолту довольно ровно встает, а вот сетевые затыки возникают ПОЧТИ ВСЕГДА, как в САБЖЕ - сетевуху поменяли и уже лучше стало...