Home > SQL Performance Tuning > การทำ Performance Tuning SQL Query เบื้องต้น (part 3 – ขั้นตอนในการ Tuning ต่อ)

การทำ Performance Tuning SQL Query เบื้องต้น (part 3 – ขั้นตอนในการ Tuning ต่อ)


จากใจผู้เขียน :

“จากบทความต่างๆ ที่ผมได้ post ลงไปใน blog นี้ ผมได้พบว่ามี blogger บางท่าน ได้นำข้อมูลต่างๆ จาก blog ผมไป post ต่อ โดย copy ไป และวางใน blog ของท่าน ผมอยากจะบอกว่าเนื้อหาทั้งหมดนั้น บางอย่างผมก็ได้ copy link เค้ามาเพื่อให้เกียรติหรือเครดิตกับเจ้าของเนื้อหา บางเรื่องผมได้เขียนจากประสบการณ์ทำงานทั้งหมด

ดังนั้นผมจึงอยากจะขอ ความกรุณา blogger ทุกท่าน ถ้า copy เนื้อหาของผมไป โดยเฉพาะส่วนที่ผมเขียนขึ้นมาเอง กรุณาให้เครดิตผมด้วยครับ เช่นวาง link ว่ามาจาก blog ของผมด้วยครับ อย่างน้อย ก็เป็นกำลังใจที่จะให้ผมเขียนบทความดีๆ ต่อไป”


เรามาทบทวนขั้นตอนในการ Tuning Query กันก่อนนะครับ จากประสบการณ์ของผม ควรจะมีขั้นตอนในการ Tune ดังนี้ครับ

  1. Performance Baseline Measurement
  2. Database Design
  3. Optimizing Query Syntax
  4. Index Strategy
  5. Reduce Locking and Blocking
  6. Database Server Configuration
  7. Data Warehouse Strategy
  8. Hardware Upgrade Strategy

คราวที่แล้วผมได้อธิบายไปจนถึงในขั้นตอนที่ 4 ขอต่อในขั้นตอนที่ 5 เลยนะครับ

5) Reduce Locking and Blocking

การใช้งาน Database ปกติแล้วเรามักจะใช้อยู่ใน Multi-User Environment เราก็ย่อมจะมีปัญหาเรื่องการแย่งกันใช้แน่นอนครับ

ผมจะยกตัวอย่างง่ายๆ สมมุติว่า ถ้าเรามี Server 2 ตัว ที่มี spec เหมือนกัน และมีขนาดฐานข้อมูลที่เท่ากัน แต่มีจำนวน user ไม่เท่ากัน ลองทายดูสิครับว่า Server ตัวไหนจะทำงานได้ช้ากว่า แน่นอนครับ Server ที่มีจำนวน User มากกว่านั่นเอง

เหตุผลที่ทำให้ช้ากว่าก็มีเหตุผลง่ายๆ น่ะครับ คือการแย่งกันใช้นั่นเอง (Data Contension) ก็เป็นเรื่องธรรมดาแหล่ะครับ ที่ data มีอยู่ชุดเดียวแต่คนที่จะใช้ data (User) กับมีหลายคน ก็ต้องมีการแย่งกันหรือต้องรอ (Queue)

แต่ไม่ว่าจะเลือกวิธีใดก็จะยึดหลักการคล้ายๆ กันก็คือ ลดจำนวน user ที่แย่งกันใช้ในเวลาเดียวกัน (Concurrent) หรือไม่ก็ทำอย่างไรให้ user คนที่เข้ามาใช้งานพร้อมๆ กันไม่ต้องรอ (reduce wait lock) เพราะโดยตามปกติแล้ว เมื่อมี User เข้ามาใช้ข้อมูลชุดเดียวกันพร้อมๆ กัน, User คนแรกจะทำการ lock ข้อมูล เพื่อป้องกันไม่ให้ user คนที่เข้ามาทีหลังมาแย่งใช้ข้อมูลชุดเดียวกันอยู่แล้ว ดังนั้น user ที่เข้ามาทีหลังจะต้องเกิดการรอ จนกว่า user คนแรกจะปิดการใช้งาน data ออกไปเอง แต่เราก็สามารถเลือกที่จะไม่รอก็ได้ครับ

ก็มีอยู่หลายวิธีนะครับ ที่จะแก้ปัญหา ยกตัวอย่างเช่นการทำ Server Farm, Replication, Data Mirror หรือแม้กระทั่งการทำ Transaction Isolation Level เป็นต้น

6) Database Server Configuration

การจัดการเกี่ยวกับเรื่อง Server Configuration ก็มีความสำคัญไม่ยิ่งหย่อนไปกว่ากัน ยกตัวอย่างดังตารางด้านล่างครับ

SQL Server
Configuration Settings
Advanced
Setting?
Requires
Restart?
Default Value Current Value
affinity mask Yes Yes 0  
awe enabled Yes Yes 0  
cost threshold for parallelism Yes No 5
cursor threshold Yes No -1
fill factor (%) Yes Yes 0
index create memory (KB) Yes No 0
lightweight pooling Yes Yes 0
locks Yes Yes 0
max degree of parallelism Yes No 0  
max server memory (MB) Yes No 2147483647  
max text repl size (B) No No 65536  
max worker threads Yes Yes 255  
min memory per query (KB) Yes No 1024  
min server memory (MB) Yes No 0  
nested triggers No No 1  
network packet size (B) Yes No 4096  
open objects Yes Yes 0  
priority boost Yes Yes 0  
query governor cost limit Yes No 0  
query wait (s) Yes No -1  
recovery interval (m) Yes No 0  
scan for startup procs Yes No 0  
set working set size Yes Yes 0  
user connections

Reference: http://www.sql-server-performance.com/articles/per/performance_audit_part4_p1.aspx

ยกตัวอย่างเช่น เรื่อง Fill Factor (รายการที่ 5) เป็นกำหนดค่าเพื่อแก้ปัญหาเกี่ยวกับการใช้ Index คือเมื่อเราเพิ่ม index เข้าไปมากๆ จะมีผลทำให้การ Select เร็วขึ้นก็จริง แต่จะมีผลข้างเคียงคือทำให้ การ Insert ข้อมูลช้าลง การกำหนดค่า Fill Factor ที่เหมาะสมจะช่วยทำให้ การ Insert เร็วขึ้นนั่นเอง

ผมจะลองยกอีกสัก config นึงก็คือ AWE – Advanced Windows Extension (รายการที่ 2) ในบางครั้งถึงแม้จะมี memory อยู่มากมายก็ตาม เป็นการกำหนดให้ SQL Server 32 bits สามารถมองเห็น Memory เกินกว่า 4GB ได้ เพื่อเพิ่มพื้นที่ Memory ให้กับ SQL Server ผลก็คือจะทำให้เพิ่ม Performance ขึ้นมานั่นเองครับ

7) Data Warehouse Strategy

หลังจากที่ได้ลองทำทุกวิถีทางไปเรียบร้อยแล้ว แต่ถ้ามันยังไม่ได้ผลมากมายตามที่ต้องการ ก็คงถึงขั้นตอนต่อไปแล้วหล่ะครับ คือการทำ Data Warehouse

อย่างที่ผมเคยกล่าวไปในตอนที่ 2 (click) นี่เป็น Database Design ที่นำเอาข้อดีของ Database Architecture แต่ละแบบมาผสมกัน แต่ก็มีเสียก็คืออาจจะต้องมีค่าบำรุงรักษาสูงขึ้น เพราะฉะนั้นถ้าจะพิจารณานำ Data Warehouse ไปใช้ ก็ควรจะวิเคราะห์ก่อนว่าคุ้มค่าที่จะลงทุนหรือไม่ครับ

8 ) Hardware Upgrade Strategy

สุดท้ายจริงๆ ก็คือการขยาย Server น่ะแหล่ะครับ ประมาณว่าถ้าใช้ 1 เครื่องแล้วยังช้า ก็ต้องขยายเป็น 2 Servers, 4 Server, 8 Servers ไปเรื่อยๆ ครับ ถ้าใช้ 100 Servers แล้วยังช้าอยู่ก็ให้มันรู้ไปครับ

ตัวอย่างนึงก็ยกเข้ามาประกอบในกรณีนี้ได้ดีก็คือ Google ครับ, Google เป็นระบบ Database ที่มีขนาดใหญ่ที่สุดในโลกก็ว่าได้ครับ เพราะว่า Google เก็บข้อมูลทุกอย่างที่อยู่ใน Internet ของโลก ทั้งหมด เท่าที่ผมทราบ Google น่าจะมี server ทั้งหมดทั่วโลกไม่ต่ำกว่า 600,000 Servers น่ะครับ

สรุปขั้นตอนในการ Tuning

สรุปว่าการ Tuning นั้น ควรจะทำเท่าที่เราทำได้ก่อน เพื่อที่เราอาจจะเสียเงินโดยไม่จำเป็นก็ได้ โดยอาจจะเริ่ม Tuning ในส่วนที่เป็น software หรือว่าการ config เพื่อให้ได้ performance ที่ดีที่สุดก่อนที่คิดจะลงทุน update ทางด้าน Hardware ต่อไปครับ

เปิดอบรมหลักสูตร SQL Tuning (Click)

 

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: