SQL Server: what is RESOURCE_QUEUE in waitstats?

[dim635csi]

What else do you see? Something is wrong with damn good SQL server with Xeon and databases on SAN.

Thank you!


dbcc sqlperf(waitstat)

Wait Type Requests Wait Time Signal Wait Time
-------------------------------- ------------------------ ------------------------ ------------------------
MISCELLANEOUS 42.0 0.0 0.0
LCK_M_SCH_S 0.0 0.0 0.0
LCK_M_SCH_M 0.0 0.0 0.0
LCK_M_S 127.0 42080.0 0.0
LCK_M_U 0.0 0.0 0.0
LCK_M_X 0.0 0.0 0.0
LCK_M_IS 0.0 0.0 0.0
LCK_M_IU 0.0 0.0 0.0
LCK_M_IX 0.0 0.0 0.0
LCK_M_SIU 0.0 0.0 0.0
LCK_M_SIX 0.0 0.0 0.0
LCK_M_UIX 0.0 0.0 0.0
LCK_M_BU 0.0 0.0 0.0
LCK_M_RS_S 0.0 0.0 0.0
LCK_M_RS_U 0.0 0.0 0.0
LCK_M_RIn_NL 0.0 0.0 0.0
LCK_M_RIn_S 0.0 0.0 0.0
LCK_M_RIn_U 0.0 0.0 0.0
LCK_M_RIn_X 0.0 0.0 0.0
LCK_M_RX_S 0.0 0.0 0.0
LCK_M_RX_U 0.0 0.0 0.0
LCK_M_RX_X 0.0 0.0 0.0
SLEEP 348592.0 3.4722054E+8 3.4722045E+8
IO_COMPLETION 1223.0 4377.0 0.0
ASYNC_IO_COMPLETION 22.0 31.0 0.0
RESOURCE_SEMAPHORE 0.0 0.0 0.0
DTC 0.0 0.0 0.0
OLEDB 18.0 1219.0 871604.0
FAILPOINT 0.0 0.0 0.0
RESOURCE_QUEUE 141964.0 1.0409206E+9 3.472216E+8
ASYNC_DISKPOOL_LOCK 276.0 0.0 0.0
UMS_THREAD 0.0 0.0 0.0
PIPELINE_INDEX_STAT 0.0 0.0 0.0
PIPELINE_LOG 0.0 0.0 0.0
PIPELINE_VLM 0.0 0.0 0.0
WRITELOG 32526.0 17264.0 359.0
PSS_CHILD 0.0 0.0 0.0
EXCHANGE 0.0 0.0 0.0
XCB 0.0 0.0 0.0
DBTABLE 0.0 0.0 0.0
EC 0.0 0.0 0.0
TEMPOBJ 0.0 0.0 0.0
XACTLOCKINFO 0.0 0.0 0.0
LOGMGR 0.0 0.0 0.0
CMEMTHREAD 33.0 95.0 15.0
CXPACKET 0.0 0.0 0.0
PAGESUPP 0.0 0.0 0.0
SHUTDOWN 0.0 0.0 0.0
WAITFOR 0.0 0.0 0.0
CURSOR 0.0 0.0 0.0
EXECSYNC 0.0 0.0 0.0
LATCH_NL 0.0 0.0 0.0
LATCH_KP 0.0 0.0 0.0
LATCH_SH 0.0 0.0 0.0
LATCH_UP 0.0 0.0 0.0
LATCH_EX 67477.0 32.0 16.0
LATCH_DT 0.0 0.0 0.0
PAGELATCH_NL 0.0 0.0 0.0
PAGELATCH_KP 0.0 0.0 0.0
PAGELATCH_SH 17677.0 1486.0 1486.0
PAGELATCH_UP 97.0 0.0 0.0
PAGELATCH_EX 45.0 77.0 47.0
PAGELATCH_DT 0.0 0.0 0.0
PAGEIOLATCH_NL 0.0 0.0 0.0
PAGEIOLATCH_KP 0.0 0.0 0.0
PAGEIOLATCH_SH 56073.0 388877.0 486.0
PAGEIOLATCH_UP 160.0 46.0 0.0
PAGEIOLATCH_EX 1202.0 8955.0 16.0
PAGEIOLATCH_DT 0.0 0.0 0.0
TRAN_MARK_NL 0.0 0.0 0.0
TRAN_MARK_KP 0.0 0.0 0.0
TRAN_MARK_SH 0.0 0.0 0.0
TRAN_MARK_UP 0.0 0.0 0.0
TRAN_MARK_EX 0.0 0.0 0.0
TRAN_MARK_DT 0.0 0.0 0.0
NETWORKIO 35330.0 33171.0 0.0
Total 702884.0 1.3886388E+9 6.953161E+8

(77 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

[Dmitry67]

А удалось ли локализовать этот wait, хоть в како месте ? sp ? что делает ?

[dim635csi]

Дима, ето не sp, ето Castor кидаюший objects в базу черес JDBC, actually it does sp_execute(), или как там. Хочет - быстро, а хочет - медленно, и никак не предсказать - когда - как...

[Dmitry67]

А что если trace построить ? SQL profile ?

[dim635csi]

in this company I need sysadm from other dept. to run Profiler.

I am J2 prog, so I have to tune JVM instead and it doesn't help ...

[Dmitry67]

Ну так все значит. Стрелки переведены, relax

[dim635csi]

"Глеб, я же понять хочу!.." (C)

[tengiz]

dim635csi, а в чём исходная проблема?

[dim635csi]

tengiz,

erratic performance of ORM (Castor) when it does inserts/updates to 9 tables (they represent classes, records - objects) on MS SQL 8.0 on W2K (hyperthreaded Xeon, 4Gb, SAN).

Tables have no PK/indices, just identity fields. After all dependent objects created, master record is inserted and then all dependents are updated with its identity to reflect relation between the objects. db is set to Simple recovery model

The creation time for the one hierarchy "master-deps" varies from 100ms to 1s with no visible reasons. Doesn't depend on the number of records in the database. Sometimes less powerful box with the same code running may give the same speed.

[Dmitry67]

1 Tables have no PK/indices, just identity fields.
2 After all dependent objects created, master record is inserted and then all dependents are updated with its identity to reflect relation between the objects.
3 db is set to Simple recovery model

Все странно
1 почему не созать clustered index по identity ? А индексов что ВООБЩЕ нет ? А FK есть ? Тогда вот Вам и ответ
2 Обычно делает наоборот. Кстати, а пока знаечение master identity неизвестно, то какое значение присваивается всем dependents ? Как не до конца вставленные dependents различаются ?
3 Для production странно. Или у Вас тоже используют аппаратные методы backup от EMC ?
3

[dim635csi]

Все странно
1 почему не созать clustered index по identity ? А индексов что ВООБЩЕ нет ? А FK есть ? Тогда вот Вам и ответ
2 Обычно делает наоборот. Кстати, а пока знаечение master identity неизвестно, то какое значение присваивается всем dependents ? Как не до конца вставленные dependents различаются ?
3 Для production странно. Или у Вас тоже используют аппаратные методы backup от EMC ?
3

1. есть две части процесса - legacy migration (once, should be fast, but tons of data) и собственно арр - во второй индексы/FK есть, но они создаются _после_ завершения migration. Migration never reads, just inserts/updates, so why you need index?

2. у dependents тоже есть свои identities

3. это еще не production, в migration рестарт kills last inserted master/dependents anyway, everything else should be ok - every master/dependents insert is the one transaction.

[alex_127]

RESOURCE_SEMAPHORE

If it is showing the right thing it is used in 2 places:
1. Throttle number of concurent optimizations in the server (I believe it is 4 per CPU). I.e. if you have 4 procs then simultaneousely you can compile only 16 sprocs, rest will wait
2. Memory grants. Let's suppose that your query needs 1000 buffers for sort, but the whole system has only 3000 buffers. Before starting query makes "reservation" stating that it would need 1000 buffers. Server assumes that out of 3000 buffers not more then say, 40% are allowed for such operations. So what is left while query is running is 200 buffers - and if you attempt to ran similar query again it will wait until first one terminated. It is little more compilcated then that in the case if number of currently running queries is small but for heavy loaded server it is about correct.

[Dmitry67]

1. есть две части процесса - legacy migration (once, should be fast, but tons of data) и собственно арр - во второй индексы/FK есть, но они создаются _после_ завершения migration.

2 Migration never reads, just inserts/updates, so why you need index?

3. это еще не production, в migration рестарт kills last inserted master/dependents anyway, everything else should be ok - every master/dependents insert is the one transaction.

1 Понял, это заливка
2 А как update находит запись которую нужно делать update ? Какое where у этого update ? Если индексов нет то любой update будет делать full table scan по определению. И, кстати, попадать на все возмножные блокировки
3 Если база большая то перед созданием индексов лучше поставить logging mode не Simple, а Bulk_log

[dim635csi]

1. есть две части процесса - legacy migration (once, should be fast, but tons of data)

2 Migration never reads, just inserts/updates, so why you need index?

3. это еще не production, в migration рестарт kills last inserted master/dependents anyway, everything else should be ok - every master/dependents insert is the one transaction.

1 Понял, это заливка
2 А как update находит запись которую нужно делать update ? Какое where у этого update ? Если индексов нет то любой update будет делать full table scan по определению. И, кстати, попадать на все возмножные блокировки
3 Если база большая то перед созданием индексов лучше поставить logging mode не Simple, а Bulk_log

1. хитрая такая, actually it's legacy conversion, but you're right in final terms

2. проверил - there is no updates - it is possible to sort our create() hierarchy such way you're always know related object ID (OID) before creation. Castor not so bad as it seems...

3. good! - will try, but needs sysadm...

Dmitry67, alex127 - большое спасибо!! Буду держать в курсе, если интересно

[dim635csi]

Дима67, а чем пыво во Францию посылать?

INSERTы-INSERTAMи - а в bridge table, которая many2many реализует все же один index пропустили. Теперь все летает просто. Больше спасибо за creative thinking...

D.

[Dmitry67]

О, нашлось ! Ну будете в Париже, с Вас кофе

[dim635csi]

"опять хочу в Париж..."