คำถามติดแท็ก performance

การประเมินว่าระบบทำงานได้ดีพอที่จะเหมาะสมกับวัตถุประสงค์หรือไม่ โดยทั่วไปแล้วประสิทธิภาพหมายถึงความเร็วที่ระบบดำเนินการเสร็จสิ้นหรือชุดของการดำเนินงานเมื่อเวลาผ่านไป


2
Redis ใช้หน่วยความจำและล่มทั้งหมด
เซิร์ฟเวอร์ redis v2.8.4 กำลังทำงานบน Ubuntu 14.04 VPS พร้อม RAM 8 GB และพื้นที่สลับ 16 GB (บน SSD) อย่างไรก็ตามhtopแสดงให้เห็นว่าredisเพียงลำพังกำลัง22.4 Gหน่วยความจำ! redis-serverในที่สุดก็ล้มเหลวเนื่องจากออกจาก memeory MemและSwpทั้งสองโจมตี 100% จากนั้นredis-serverจะถูกฆ่าพร้อมกับบริการอื่น ๆ จากdmesg: [165578.047682] Out of memory: Kill process 10155 (redis-server) score 834 or sacrifice child [165578.047896] Killed process 10155 (redis-server) total-vm:31038376kB, anon-rss:5636092kB, file-rss:0kB การเริ่มต้นใหม่redis-serverจากความผิดพลาดของ OI หรือservice redis-server …

4
คำสั่ง SELECT จากระยะไกลช้าเนื่องจาก“ เวลาในการประมวลผลลูกค้า” ที่ยาวนาน แต่รวดเร็วในพื้นที่
ในขณะที่เชื่อมต่อกับเซิร์ฟเวอร์ที่ใช้งานจริงของเรา (SQL Server 2008, เครื่องจักรที่ทรงพลังมาก), คำสั่ง SELECT นี้ใช้เวลา2 วินาที , กระจายกลับทุกช่อง (รวมข้อมูล 4 MB) SELECT TOP (30000) * FROM person WITH(NOLOCK); จากการใด ๆอื่น ๆกล่องบนเครือข่ายเดียวกัน (การเชื่อมต่อใช้การตรวจสอบ SQL หรือ Windows Authentication) แบบสอบถามเดียวกันจะใช้เวลา1 นาที 8 วินาที ฉันกำลังทดสอบด้วยคำสั่งง่ายๆนี้เพื่อแสดงให้เห็นว่าไม่ใช่ปัญหาการจัดทำดัชนีหรือปัญหาเกี่ยวกับแบบสอบถาม (เรามีปัญหาด้านประสิทธิภาพด้วยข้อความค้นหาทั้งหมดในขณะนี้ ... ) แถวมาเป็นกลุ่มและไม่ใช่ทั้งหมดในคราวเดียว ฉันได้แถวแรกทันทีจากนั้นรอประมาณ 1 นาทีเพื่อให้แถวเข้ามา นี่คือสถิติลูกค้าของแบบสอบถามเมื่อมีการเรียกใช้จากกล่องระยะไกล: Query Profile Statistics Number of INSERT, DELETE and …

3
ประสิทธิภาพการทำงานยอดเยี่ยมใช้ CAST ใน T-SQL
เรามีเครื่องกำเนิดไฟฟ้า SQL ที่ส่งเสียง SQL งบเงื่อนไขทั่วไปสำหรับเขตข้อมูลที่ระบุไว้ (ซึ่งเพื่อประโยชน์ของการอภิปราย: เราจะติดป้ายว่าเป็นmyField) ถ้าmyFieldเป็นประเภทที่เราสามารถทำได้เปรียบเทียบข้อมูลดังกล่าวกับสายเช่นเพื่อให้เป็น:NVARCHARmyField = 'foo' NTEXTแต่นี้ไม่ทำงานสำหรับเขตข้อมูลประเภท CAST(myField as NVARCHAR(MAX)) = 'foo'ดังนั้นเราจึงต้องทำเปรียบเทียบกับหล่อ: ประสงค์ในการทำงานความจริงเรื่องนี้ถ้าmyFieldเป็นประเภทหรือNVARCHARNTEXT อะไรคือผลงานยอดเยี่ยมของการทำนักแสดงดังกล่าวในสนามที่มีประเภทอยู่แล้วNVARCHAR ? ฉันหวังว่า SQL Server เป็นพอสมาร์ทที่จะรับรู้แบบไดนามิกที่myFieldมีอยู่แล้วจากประเภทNVARCHAR(ประสิทธิภาพการเปลี่ยนCASTเป็นไม่มี-op)

3
ข้อผิดพลาดขนาดดัชนีสูงสุดของแถว
มีขอบเขตบนสำหรับarrayคอลัมน์หรือไม่? ฉันได้รับข้อผิดพลาดนี้เมื่อแทรกเข้าไปในฟิลด์อาร์เรย์ - PG::Error: ERROR: index row size 3480 exceeds maximum 2712 for index "ix_data" นี่คือคำนิยามตารางของฉัน - create table test_array(id varchar(50), data text[]); ALTER TABLE test_array ADD PRIMARY KEY (id); CREATE INDEX ix_data ON test_array USING GIN (data); ฉันต้องการดัชนีในฟิลด์อาร์เรย์เนื่องจากฉันกำลังทำการค้นหาบางอย่างกับมัน

1
แนวปฏิบัติที่ดีที่สุดในปัจจุบันเกี่ยวกับการปรับขนาด varchar ใน SQL Server คืออะไร
ฉันพยายามเข้าใจวิธีที่ดีที่สุดในการตัดสินใจว่าคอลัมน์ varchar ขนาดใหญ่ควรเป็นอย่างไรทั้งจากมุมมองการจัดเก็บและประสิทธิภาพ ประสิทธิภาพ จากการวิจัยของฉันดูเหมือนว่าควรใช้ varchar (สูงสุด) เฉพาะในกรณีที่คุณต้องการเท่านั้น นั่นคือถ้าคอลัมน์จะต้องรองรับมากกว่า 8000 ตัวอักษรเหตุผลหนึ่งคือการขาดการจัดทำดัชนี (แม้ว่าฉันน่าสงสัยเล็กน้อยของการจัดทำดัชนีในเขตข้อมูล varchar โดยทั่วไปฉันค่อนข้างใหม่กับหลักการ DB แม้ว่าอาจจะไม่มีมูลเลย ) และการบีบอัด (ยิ่งกังวลเรื่องพื้นที่เก็บข้อมูล) ในความเป็นจริงแล้วคนทั่วไปดูเหมือนจะแนะนำให้ใช้เฉพาะสิ่งที่คุณต้องการเมื่อทำ varchar (n) .... การ oversize ไม่ดีเพราะการสืบค้นจะต้องคำนึงถึงขนาดสูงสุด แต่ก็มีการระบุด้วยว่าเครื่องยนต์จะใช้ขนาดครึ่งหนึ่งที่ระบุไว้เป็นค่าประมาณขนาดเฉลี่ยจริงของข้อมูล นี่หมายความว่าเราควรกำหนดจากข้อมูลว่าขนาดเฉลี่ยคืออะไรเพิ่มขนาดเป็นสองเท่าและใช้เป็น n สำหรับข้อมูลที่มีค่าความแปรปรวนต่ำมาก แต่ไม่เป็นศูนย์ นี่หมายถึงการขยายขนาดเกินขนาดสูงสุด 2 เท่าซึ่งดูเหมือนจะมาก แต่อาจไม่ใช่หรือ ข้อมูลเชิงลึกจะได้รับการชื่นชม ที่เก็บข้อมูล หลังจากอ่านเกี่ยวกับวิธีการทำงานของหน่วยเก็บข้อมูลแบบ in-row และ out-of-row และโปรดทราบว่าการจัดเก็บข้อมูลจริงนั้น จำกัด อยู่ที่ข้อมูลจริงฉันคิดว่าตัวเลือกของ n นั้นมีพื้นที่เก็บข้อมูลน้อยมากหรือไม่มีเลย ทำให้แน่ใจว่ามันใหญ่พอที่จะเก็บทุกอย่างไว้ได้) แม้แต่การใช้ varchar (สูงสุด) …

3
ปัญหาประสิทธิภาพการทำงานที่สำคัญใน SQL Server ที่ผลิตของเราฉันจะแก้ไขปัญหานี้ได้อย่างไร
คำถามนี้เป็นคำถามที่ตามมาสำหรับคำถามนี้: ปัญหาประสิทธิภาพการทำงานที่แปลกกับ SQL Server 2016 ตอนนี้เรามีประสิทธิภาพด้วยระบบนี้ แม้ว่าฐานข้อมูลแอปพลิเคชันอื่นจะถูกเพิ่มไปยัง SQL Server นี้ตั้งแต่โพสต์ล่าสุดของฉัน นี่คือสถิติของระบบ: 128 GB RAM (หน่วยความจำสูงสุด 110GB สำหรับ SQL Server) 4 คอร์ที่ 2.6 GHz การเชื่อมต่อเครือข่าย 10 GBit ที่เก็บข้อมูลทั้งหมดใช้ SSD ไฟล์โปรแกรมไฟล์บันทึกไฟล์ฐานข้อมูลและ tempdb อยู่บนพาร์ติชันแยกต่างหากของเซิร์ฟเวอร์ Windows Server 2012 R2 VMware เวอร์ชัน HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17 เครื่องมือ VMware รุ่น 10.0.9 สร้าง 3917699 Microsoft SQL Server 2016 (SP1) (KB3182545) …

3
วิธีตอบว่าทำไมเราต้องมีดัชนีหรือแบบสอบถามต้องเปลี่ยน
ฉันเป็นจูเนียร์ DBA ที่มีประสบการณ์ 3 ปี งานของเราคือการปรับแต่งแบบสอบถามหรือให้คำแนะนำกับนักพัฒนาว่าควรเขียนโค้ดเฉพาะหรือดัชนีใหม่ คำถามง่ายๆหนึ่งคำถามที่ทีมพัฒนาถามบ่อยคือ: "เมื่อวานมันวิ่งได้ดี และเราจะถูกขอให้ตรวจสอบด้านโครงสร้างพื้นฐาน ปฏิกิริยาแรกที่เกิดขึ้นกับปัญหาใด ๆ มักจะทำให้เกิดความผิดพลาดสูงสุดในโครงสร้างพื้นฐานซึ่งเป็นสิ่งแรกที่ถูกตรวจสอบเสมอ เราควรตอบคำถาม "สิ่งที่เปลี่ยนแปลง" โดยทีมพัฒนาอย่างไร พวกคุณเคยเผชิญกับสถานการณ์เดียวกันหรือไม่? ถ้าเป็นเช่นนั้นโปรดแบ่งปันประสบการณ์ของคุณ

2
ความเสี่ยงด้านความปลอดภัยหรือประสิทธิภาพการใช้ SQL CLR [ปิด]
ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา มีความเสี่ยงด้านความปลอดภัยหรือประสิทธิภาพโดยเฉพาะอย่างยิ่งในการใช้ CLR ใน SQL Server หรือไม่?

1
การประมาณความต้องการ IO สำหรับการใช้งาน Bursty
เรามีแอพพลิเคชั่นที่สืบค้นฐานข้อมูล SQL เป็นระยะตลอดทั้งวัน มีกิจกรรมเป็นช่วงเวลาที่ศูนย์หรือกิจกรรมเบา ๆ สลับกับคำขอแต่ละรายการสำหรับข้อมูลจำนวนมาก เมื่อคำขอเหล่านั้นเข้ามามีวัตถุประสงค์หลักคือการส่งข้อมูลอย่างรวดเร็วและวัตถุประสงค์รองคือการดำเนินการที่คุ้มค่า เนื่องจากลักษณะของแอปพลิเคชันจึงไม่น่าเป็นไปได้ที่ข้อมูล / ดัชนีจะถูกแคชใน RAM จากการค้นหาก่อนหน้า (ผู้ใช้ที่ต่างกันซึ่งทำงานกับส่วนต่าง ๆ ของข้อมูล) สำหรับระบบที่มีประสบการณ์การใช้งานค่อนข้างคงที่ฉันเคยได้ยินกฏเกณฑ์ง่าย ๆ ในการสังเกตความยาวคิวของดิสก์และเก็บหมายเลขนั้นไว้ค่อนข้างน้อย สิ่งนี้จะทำงานเป็นพิเศษใน AWS โดยที่ฉันได้เห็นกฎของหัวแม่มือว่าความยาวคิวดิสก์ 1 ต่อ 100 IOPS นั้นสมเหตุสมผล ฉันจะประเมินข้อกำหนดของ IO สำหรับระบบดังกล่าวได้อย่างไร ความยาวคิวของดิสก์เป็นตัวบ่งชี้ที่เชื่อถือได้เมื่อต้องจัดการกับข้อความค้นหาแต่ละรายการหรือไม่ มีตัวชี้วัดอื่นที่ฉันควรพิจารณาหรือไม่

1
จะปรับปรุงอัตราส่วน Hit Cache ได้อย่างไร?
จากสิ่งที่ฉันสามารถบอกได้ถึงอัตราส่วนของ Hit Cache ที่ต่ำกว่า 95% เป็นปัญหา ในกล่องของฉันค่าโฮเวอร์จาก 85 ถึง 95% ฉันจะแก้ไขปัญหานี้ได้อย่างไร เซิร์ฟเวอร์ดูเหมือนจะมี RAM มากมายจึงไม่น่าจะมีปัญหา มีอะไรอีกบ้างที่เป็นไปได้?

2
MySQL ไม่ได้ใช้ดัชนีเมื่อเข้าร่วมกับตารางอื่น
ฉันมีสองตารางตารางแรกประกอบด้วยบทความ / บล็อกโพสต์ทั้งหมดภายใน CMS บทความเหล่านี้บางส่วนอาจปรากฏในนิตยสารซึ่งในกรณีนี้พวกเขามีความสัมพันธ์กับต่างประเทศที่สำคัญกับตารางอื่นที่มีข้อมูลเฉพาะของนิตยสาร นี่คือเวอร์ชันที่เรียบง่ายของไวยากรณ์การสร้างตารางสำหรับสองตารางเหล่านี้ที่มีแถวที่ไม่จำเป็นออกมา: CREATE TABLE `base_article` ( `id` int(11) NOT NULL AUTO_INCREMENT, `date_published` datetime DEFAULT NULL, `title` varchar(255) NOT NULL, `description` text, `content` longtext, `is_published` int(11) NOT NULL DEFAULT '0', PRIMARY KEY (`id`), KEY `base_article_date_published` (`date_published`), KEY `base_article_is_published` (`is_published`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CREATE TABLE `mag_article` ( …

3
ข้อกำหนดหน่วยความจำทั่วไปสำหรับ sql server 2008 r2
ฉันไม่ได้มีประสบการณ์กับงาน DBA แต่ฉันพยายามทำกรณีขอทรัพยากรเพิ่มเติมสำหรับเซิร์ฟเวอร์ sql ของเราและหวังว่าฉันจะได้คนฉลาด ๆ มาเสนอการประมาณคร่าวๆของสิ่งที่เราควรใช้ ฉันสงสัยว่าการจัดสรรทรัพยากรไอทีให้กับเซิร์ฟเวอร์ sql ที่ใช้งานจริงของเราอยู่ในระดับต่ำ ฮาร์ดแวร์และซอฟต์แวร์: ฐานข้อมูล: sql server 2008 r2 ฐานข้อมูลองค์กร Windows: Windows 2008 r2 Enterprise 64 บิตค่อนข้างแน่ใจว่าทำงานบน VMware หน่วยประมวลผล: Intel (R) Xeon (R) CPU E7-4860 @ 2.27GHz 2.26 GHz (โปรเซสเซอร์ 2 ตัว) หน่วยความจำที่ติดตั้ง: 4GB ฮาร์ดไดรฟ์สำหรับไฟล์ฐานข้อมูล: 300GB ฮาร์ดไดรฟ์สำหรับการสำรองข้อมูล: 150GB ฮาร์ดไดรฟ์สำหรับบันทึก: 100GB การประยุกต์ใช้: เรามีฐานข้อมูลหลัก 3 …

3
โครงสร้างฐานข้อมูล SQL สำหรับ RESTful API
ฉันกำลังสร้าง RESTful API ฉันกำลังดิ้นรนที่จะตัดสินใจเกี่ยวกับวิธีที่ดีที่สุดในการออกแบบตารางฐานข้อมูลรอบทรัพยากรของฉัน ตอนแรกฉันแม้ว่าตารางต่อทรัพยากรจะเป็นวิธีที่ดี แต่ตอนนี้ฉันกังวลว่าสิ่งนี้จะส่งผลให้ตารางมีขนาดใหญ่ขึ้นอย่างทวีคูณยิ่งทำให้ห่วงโซ่ทรัพยากรมากขึ้น ตัวอย่างเช่นสมมติว่าฉันมีทรัพยากรสามอย่างคือผู้ใช้ลูกค้ายอดขาย ผู้ใช้เป็นสมาชิกของ api ของฉันลูกค้าคือลูกค้าผู้ใช้และยอดขายเป็นการซื้อโดยลูกค้าแต่ละรายไปยังบัญชีผู้ใช้ เข้าถึงทรัพยากรการขายดังนี้ GET /users/{userID}/clients/{clientID}/sales/{salesID} ดังนั้นหากมีผู้ใช้ 10 คนแต่ละคนมีลูกค้า 10 คนและสำหรับลูกค้าแต่ละรายมียอดขาย 10 รายการขนาดของตารางจะใหญ่ขึ้นเรื่อย ๆ ตามห่วงโซ่ทรัพยากรที่เราไป ฉันค่อนข้างมั่นใจว่า SQL สามารถรับมือกับตารางขนาดใหญ่ได้ แต่ฉันไม่แน่ใจว่าการอ่านและการเขียนจะทำให้ช้าลงอย่างไร ตัวอย่างข้างต้นอาจไม่ได้อธิบาย แต่ api ของฉันจะมีการเขียนเพิ่มขึ้นและอ่านเพิ่มเติมลงในห่วงโซ่ทรัพยากรที่เราไป ฉันจึงมีสถานการณ์ที่ตารางที่ใหญ่ที่สุดในฐานข้อมูลของฉันจะถูกอ่านและเขียนลงในตารางมากกว่าตารางที่เล็กกว่า นอกจากนี้ยังจำเป็นต้องเข้าร่วมตารางก่อนเรียกใช้แบบสอบถาม เหตุผลก็คือฉันอนุญาตให้ผู้ใช้แต่ละคนมีชื่อลูกค้าเหมือนกัน เพื่อหลีกเลี่ยงการรับข้อมูลไคลเอนต์ที่ไม่ถูกต้องตารางผู้ใช้และตารางไคลเอ็นต์จะถูกรวมโดย {userID} นี่เป็นกรณีขาย การเข้าร่วมตารางขนาดใหญ่และการอ่านและเขียนจะทำให้ช้าลงหรือไม่

4
ข้อความค้นหาช้าสำหรับผู้ใช้บางราย
ฉันมีแบบสอบถามสองสามข้อที่เรียกจากแอปพลิเคชันเว็บ C # .NET ซึ่งรวดเร็วสำหรับฉันเสมอ (ฉันเป็นผู้ดูแลระบบภายใน SQL Server) แต่สำหรับกลุ่มผู้ใช้ (กลุ่มโดเมนที่มีสิทธิ์ที่จำเป็น) แบบสอบถามนั้นช้ามาก จุดที่มันหมดเวลาในแอปพลิเคชัน อะไรจะทำให้การค้นหาเดียวกันที่แน่นอนนั้นทำงานต่างกันสำหรับผู้ใช้ที่ต่างกัน ข้อมูลเพิ่มเติม: แบบสอบถามเป็นแบบอินไลน์ SQL ในรหัส C # ไม่ใช่ขั้นตอนการจัดเก็บ แอปใช้การรับรองความถูกต้องของโดเมนและทั้งผู้ใช้และตัวฉันเองเรียกใช้แบบสอบถามผ่านแอป ดูเหมือนว่าปัญหานี้เป็นแผนที่แตกต่างกันและมีการแคชหนึ่งครั้งดังนั้นจึงเป็นเหตุผลที่แตกต่างกันสำหรับผู้ใช้ที่ต่างกัน มีบางอย่างที่ส่งผลต่อแคชเพราะตอนนี้คิวรีช้าสำหรับฉันผ่านแอปและรวดเร็วใน SQL Server Management Studio

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.