PostgreSQL Conference Japan 2018
[B3] Let's scale-out PostgreSQL using Citus
https://www.postgresql.jp/jpug-pgcon2018
Japanese Version
[db tech showcase Tokyo 2017] D21: ついに Red Hat Enterprise Linuxで SQL Serverが使...Insight Technology, Inc.
いよいよリリースが間近に迫ったSQL Server 2017 Linux版。SQL Serverの第一人者 Dr. Kこと熊澤 幸生がリリース版を待ちきれずにRed Hat Enterprise Linux上で検証してみました。
Windows版と Linux版で果たしてSQL Serverの処理性能に差があるのか?注目の検証結果をいち早くお知らせします。
Some might think Docker is for developers only, but this is not really the case.Docker is here to stay and we will only see more of it in the future.
In this session learn what Docker is and how it works.This session will be covering core areas such as volumes, but also stepping it up to a few tips and tricks to help you get the most out of your Docker environment.The session will dive into a few examples of how to create a database environment within just a few minutes - perfect for testing,development, and possibly even production systems.
Machine Learning explained with Examples
Everybody is talking about machine learning. What is it actually and how can I use it?
In this presentation we will see some examples of solving real life use cases using machine learning. We will define Tasks and see how that task can be addressed using machine learning.
SQL Server 2017でLinuxに対応し、その延長線でDocker対応やKubernetesによる可用性構成が組めるようになりました。そしてリリースを間近に控えたSQL Server 2019ではKubernetesを活用したBig Data Cluster機能の提供が予定されており、コンテナの活用範囲はさらに広がっています。
本セッションではこれからSQL Serverコンテナに触れていくための基礎知識と実際に触れてみるための手順やサンプルをお届けします。
2. 経歴
• 1987 年よりDBAとして最初はメインフレームを経験しその後、Oracle AIX
版とWindows版に携わる
• 1997年よりBaanでPerformance & Benchmark スペシャリストとして働きそ
の後、Compaq: Windows Oracle, SQL Server en Informix benchmarksを経
験
• Compaq と HP: Unix、Windows Oracle パフォーマンスコンサルタント
• 2006-2009 Windows Integrity Engineering: Windows Itanium (eh, Oracle)
benchmarks in Redmond, WA USA.
• 2002年からSQL Server 2000の解析調査を始め、ユーザセッションごとの
wait event情報の収集やwait event tracingに携わる。後に、SQL Server
2005についても調査 see: www.sqlinternals.com
• Wait event presentation: DBForum Lalandia 2004 (SQL Server 2000)
• SQL Server waitstuff について3つの記事を発表
– www.simple-talk.com/sql/performance
• PGGM (Pension fund)にてDatabaseスペシャリストとして2010年
Netherlandsに戻る: finally SQL Server DBA!
• 現在、インサイトテクノロジー在籍
3. wait events とは?
• SQL Server が動いていなかったら: 待機状態
• wait event が発生したら: ‘何か’ が現状のタスク
を待ち状態にしている
• SQL Server では、待ちの発生場所を特定できる:
– Data file or transaction log IO
– Network IO
– Locks & Latches
– CPU
– 480 以上のwait の種類がある
4. 用途は?
• R = S +W : Response time = Service time +
Wait time
• Response time is key for the end user. ‘R’ はオ
ンライン response timeとなるが、‘batch’ time
を表すこともある
• Example: response time 4 seconds は、 0.2 s
CPU time と 3.8 seconds の IO time から構成
されている。 Does it make sense to optimize
CPU time? Buy faster CPUs? Build faster code?
5. A little bit of history..
• Oracle wait events は1994年に文書化されていて
(Anjo Kolk)、評価を受けている。YAPP: ‘Yet
Another Performance Profiling’ method paper.
• DBCC SQLPerf(Waitstats) 文書化されていない:
Gert Drapers と Tom Davidson が最初に取り掛か
る
• SQL Server 2005 以降はBOLにて公開されている
• Microsoft papers: Troubleshooting Performance
Problems using Queues and waits (SQL server
2005 en 2008) : Davidson ea.
6. Where do wait events come from?
• SOS Scheduler
– ‘work request’ 処理中: SQL Batch または Parallel
Query -> task
– 1 task runs on 1 scheduler on 1 CPU until:
• blocking call 発生: disk IO, network IO -> wait event, start
time and type が登録される
• Time quantum has elapsed: 4ms (always?) (scheduler and
CPU の独占を防ぐために): SOS_SCHEDULER_WAIT (and
SLEEP_TASK?)
– worker thread によりtask 処理が発生: OS thread or
Fiber (light weight pooling)
7. Task Flow
(from: SS2005 Practical Troubleshooting: Ken Henderson)
Worker available
New
Pending Runna Runni
Task Done
ble ng
Suspe
nded
PreEm
ptive
8. Wait time
• wait time の 2 つの要素:
– Resource wait time
• resource が利用可能になるまでの時間。‘suspended’ 状態
から ‘ runable’ になるまでの時間。
– Signal wait time
• resource が利用可能になるまでの時間とタスクの実継続時
間: ‘runnable’ から ‘running’ になるまでの時間。
– DMV(動的管理ビュー)のwait timeにはsignal wait
timeが含まれる.
• SQL Server バージョンによりタイミングは異なる。
SS2005 SP3 からは 1ms..ほど(詳細はこちらの link )
9. Waitsの場所
• Sys.dm_os_wait_stats (dbcc sqlperf(waitstats) ) (screenshot)
– Since startup, or dbcc sqlperf(sys.dm_os_wait_stats, clear)
– Wait time, Signal time (time: runnable->running)
• Sys.dm_os_waiting_tasks (screenshot)
• Sys.dm_exec_requests, Sysprocesses (screenshot)
• Sys.dm_io_virtual_file_stats(db_id,file_id) (screenshot)
– Io_stall_read_ms, Io_stall_write_ms and num_reads/writes.
– ‘real’ IO latency, pay attention to num_of_bytes_read/written. In most
cases 64K per read or more! (see screenshot: virtual filestats summary)
• Sys.dm_db_index_operational_stats(db_id,object_id,etc,..)
(screenshot)
• Not available in Profiler!
10. CPU timeの場所
• @@CPU_BUSY * CAST(@@TIMETICKS AS FLOAT)/1000,
@@io_BUSY * CAST(@@TIMETICKS AS FLOAT)/1000,
@@idle * CAST(@@TIMETICKS AS FLOAT)/1000)
(accumulated for this SQL Server Instance)
• ./Record/SchedulerMonitorEvent/SystemHealth/ProcessUtilization
./Record/SchedulerMonitorEvent/SystemHealth/SystemIdle
from:
select timestamp, convert(xml, record) as record
from sys.dm_os_ring_buffers
where ring_buffer_type = N'RING_BUFFER_SCHEDULER_MONITOR'
and record like '%<SystemHealth>%‘
(see: exact query from Performance Dashboard in Slide notes)
• Sys.dm_exec_sessions: cpu_time spend for this session
• Sys.dm_exec_requests: cpu_time spend for this request (also:
total_elapsed_time)
21. But…
• session, SQL 文, Batchごとのwait event を見ることができない
• Sessionかbatchのどちらがwait eventの原因なのかは推測の域
• Unless you use ‘dangerous’ tools from sqlinternals.com (see
example)
• Or use SQL Server 2008: Xevents! (demo), unfortunately no DMVs
only clumsy XML
• 多くのSQL Server動作はOracleと比較すると非同期的に実行される
(pagiolatch waits vs filestats: Oracle: db file sequential read)
• Don’t forget about CPU time: it’s still part of response time!
• Despite the fact that wait events are extremely important, there is
more to measure. But not much more..
• ..The best optimization is elimination: Only do what you need to do:
keep questioning code and (business) processes
22. 実例
• insert loop, many commits
• Broker problems
• SAN移行後、Writelog がスローダウン
• ミラーディスクにTempdbを置いたとき
Tempdb
• Batch response time breakdown: DB timeを
appserver timeと比較して
• Demo SQL Server 2008 XEvents
23. Insert loop 10k rows, commit inside or outside SQLInternals tools)
Commit Inside loop, per row. (or actually no commit, no transaction, in SSMS)
Spid Ec resource time(ms) count sig avg perc
51 0 Elapsedtime 10102 0 0 0 n/a
51 0 CPU 1890 13 0 145,3846 19 %
51 0 SOS_SCHEDULER_YIELD 0 12 0 0 0%
51 0 PAGEIOLATCH_SH 406 70 0 5,8 4%
51 0 PAGEIOLATCH_EX 15 5 0 3 0%
51 0 WRITELOG 7531 10003 390 0,7528741 75 %
51 0 Unaccounted for 260 0 0 0 3%
One Commit outside of the loop, with begin transaction:
Spid Ec resource time(ms) count sig avg perc
51 0 Elapsed time 911 0 0 0 n/a
51 0 CPU 812 1 0 812 89 %
51 0 SOS_SCHEDULER_YIELD 62 168 62 0,3690476 7%
51 0 ASYNC_NETWORK_IO 15 11 0 1,363636 2%
51 0 WRITELOG 0 1 0 0 0%
51 0 Unaccounted for 22 0 0 0 2%