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

18
ฐานข้อมูลภายในแย่ - แทนที่หรือเชยฮาร์ดแวร์ที่มัน
ดังนั้น - เรามีฐานข้อมูลภายใน บริษัท ซึ่งเป็นประเภทปกติ: จัดการลูกค้าโทรศัพท์ข้อเสนอการขายและข้อตกลง / รูปแบบของลูกค้า เป็น Front-End ของ Access 2000 และ SQL Server 2000 Standard back-end เซิร์ฟเวอร์เดียว, Xeon คู่สอง 3.2GHz, 2GB RAM, Windows Server 2003, รับ CPU ประมาณ 40% ตลอดทั้งวัน, แผ่กระจายไปทั่วทั้ง 4 คอร์ที่มองเห็นได้จาก OS (HT) ฐานข้อมูลส่วนหลังได้รับการออกแบบมาไม่ดีและมีการเติบโตแบบออร์แกนิกมากกว่า 10 ปีขึ้นไปดูแลโดยบุคคลที่มีทักษะน้อยกว่า มันเป็นมาตรฐานที่ไม่ดีและปัญหาที่ชัดเจนบางอย่างรวมถึงตารางที่มีจำนวนหมื่นแถวโดยไม่มีคีย์หลักหรือดัชนีซึ่งใช้อย่างมากในการรวมหลายตารางสำหรับบางส่วนที่ใช้งานหนักที่สุดของระบบ (เช่น แอปพลิเคชันตัวจัดการการโทรที่อยู่บนจอภาพที่สองของทุกคนเป็นเวลา 8 ชั่วโมงต่อวันและเรียกใช้แบบสอบถามที่ไม่มีประสิทธิภาพขนาดใหญ่ทุกสองสามวินาที) ส่วนหน้านั้นไม่ได้ดีไปกว่านี้มันเป็นระเบียบโดยทั่วไปของหลายร้อยรูปแบบแบบสอบถามที่ซ้อนกันที่บันทึกไว้ SQL ที่ฝังตัวที่เขียนได้ไม่ดีในรหัส VBA, …

2
วิธีคำนวณ max_connections สำหรับ PostgreSQL และ default_pool_size สำหรับ pgbouncer
มีกฎหรือสิ่งที่ฉันสามารถใช้ในการคำนวณตัวเลขที่ดีสำหรับmax_connections, default_pool_sizeและmax_client_conn? ค่าเริ่มต้นเป็นเลขคี่ PostgreSQL มีค่าเริ่มต้นเป็น max_connections = 100 ในขณะที่ pgbouncer มีค่าเริ่มต้นเป็น default_pool_size = 20 ไม่ควร default_pool_size สูงกว่า max_connections เสมอหรือ มิฉะนั้นประเด็นคืออะไร? ฉันคิดว่า pgbouncer ตั้งใจให้เราจัดการการเชื่อมต่อได้มากขึ้นโดยลดค่าใช้จ่ายลง (โดยใช้การเชื่อมต่อของ PostgreSQL อีกครั้ง) ฉันสับสน ฉันกำลังมองหาคำแนะนำคล้ายกับที่พบในวิกิของ PostgreSQLเช่น "พารามิเตอร์นี้ควรเป็น ~ 50% ของหน่วยความจำของคุณ" ฉันจำได้ว่ามีสเปรดชีตสำหรับ MySQL ที่จะให้คุณคำนวณพารามิเตอร์ประเภทนี้ มันยอดเยี่ยมมากที่มีบางอย่างเช่น PostgreSQL / pgbouncer

6
SQL Server Express สำหรับฐานข้อมูลการผลิต?
เรากำลังจะเปิดตัวแอปพลิเคชันธุรกรรมทางเว็บคู่ / ภายในที่ลูกค้าแต่ละรายมีฐานข้อมูลของตนเอง แต่ละฐานข้อมูลมีขนาดเล็กมาก - แต่ละอันมีขนาดไม่เกิน 50MB ดังนั้นเราจึงสงสัยว่าจะใช้ SQL Express 2008 แทน SQL Server แบบเต็มหรือไม่ สิ่งนี้ดูเหมือนว่าจะมีข้อได้เปรียบในการกระจายดิสก์ I / O บนเซิร์ฟเวอร์ในขณะที่ประหยัดจำนวนมาก $$$ (ตั้งแต่ไดรฟ์ขนาด 15K และเซิร์ฟเวอร์แบบดูอัลคอร์ที่ใช้แล้วมีราคาไม่แพง) ถ้าในบางครั้งเราต้องการเซิร์ฟเวอร์มากเกินไปเราสามารถอัปเกรดเป็น SQL Server ... แต่ด้วยผู้ใช้ภายในหลายสิบคนตอนนี้ดูเหมือนว่าจะแพงเกินไป (โดยเฉพาะเมื่อเราต้องการกล่อง failover) หน่วยความจำ 1GB และการใช้งาน 4 คอร์ในโปรเซสเซอร์เดียวไม่ได้ฟังดู จำกัด เกินไปเพราะขนาดฐานข้อมูลขนาดเล็กของเรา เราจะไม่มีผู้ใช้งานพร้อมกันมากกว่า 200 คนและการดำเนินการส่วนใหญ่จะเป็นธุรกรรมมากขึ้น (ซึ่งดูเหมือนว่าจะชอบดิสก์ความเร็วสูงจำนวนมากมากกว่า RAM / CPU ที่หนักใช่ไหม?) ฉันไม่มีข้อได้เปรียบใด ๆ ของ SQL …

2
มีเกณฑ์เปรียบเทียบสมรรถนะ MySQL เพื่อวัดผลกระทบของ utf8_unicode_ci เทียบกับ utf8_general_ci หรือไม่?
ผมอ่านที่นี่และมีว่าการใช้utf8_unicode_ciการเปรียบเทียบเพื่อให้แน่ใจว่าการรักษาที่ดีขึ้นของข้อความ Unicode (ตัวอย่างเช่นมัน knowns วิธีการขยายตัวอักษรเช่น 'œ' เป็น 'OE' สำหรับการค้นหาและการสั่งซื้อ) เมื่อเทียบกับการเริ่มต้นutf8_general_ciซึ่งโดยทั่วไปเพียงแถบกำกับ แต่น่าเสียดายที่ทั้งสองแหล่งข่าวระบุว่าจะช้ากว่าเล็กน้อยutf8_unicode_ciutf8_general_ci ดังนั้นคำถามของฉันคืออะไร "ช้าลงเล็กน้อย" หมายความว่าอย่างไร มีใครบ้างที่ใช้มาตรฐาน? เรากำลังพูดถึงผลกระทบของประสิทธิภาพการทำงาน -0.01% หรือมากกว่า -25% ขอบคุณสำหรับความช่วยเหลือของคุณ.

3
ความสำคัญของตำแหน่งที่ตั้งของการติดตั้ง Microsoft SQL Server
ฉันมีเซิร์ฟเวอร์ที่มีดิสก์ช้าราคาถูกและดิสก์เร็วราคาแพง ฉันต้องการใช้ดิสก์ที่มีราคาแพงสำหรับทุกสิ่งที่มันสำคัญที่มันเร็วเช่นฐานข้อมูลของฉัน เพื่อประหยัดเงินฉันต้องการใช้ดิสก์ที่ช้าสำหรับทุกสิ่งที่ไม่ได้สร้างความแตกต่างอย่างมากไม่ว่าจะเร็วหรือช้าเช่นการสำรองข้อมูล ตอนนี้คำถามของฉันคือฉันควรติดตั้ง Microsoft SQL Server ของฉันในช้าหรือเร็วดิสก์? (เพื่อความชัดเจนฉันจะวางฐานข้อมูลของฉันลงบนดิสก์อย่างรวดเร็วไม่ว่าอะไรจะเกิดขึ้นดังนั้นคำถามของฉันเกี่ยวข้องกับตำแหน่งของการติดตั้งเท่านั้น)

3
I / O มากเกินไปที่สร้างขึ้นโดยกระบวนการตัวรวบรวมสถานะของ postgres
ฉันใช้ XenServer กับเครื่องเสมือนหลายเครื่องที่มีฐานข้อมูลท้องถิ่น postgres แม้ว่าแอปพลิเคชันทั้งหมดจะไม่ได้ใช้งานและฐานข้อมูลไม่ได้ใช้งาน แต่ vm แต่ละตัวจะก่อให้เกิดทราฟฟิกเครือข่ายการจัดเก็บข้อมูลคงที่ซึ่งลดประสิทธิภาพของอุปกรณ์เก็บข้อมูล iscsi หลังจากทำงานiotopฉันได้สังเกตเห็นว่ากระบวนการประมวลผลตัวรวบรวมสถานะ postgres กำลังเขียนลงดิสก์อย่างต่อเนื่องในอัตราประมาณ 2 MByte / s ฉันปิดการรวบรวมสถิติโดยการแก้ไข/etc/postgresql/8.4/main/postgresql.conf: #------------------------------------------------------------------------------ # RUNTIME STATISTICS #------------------------------------------------------------------------------ # - Query/Index Statistics Collector - track_activities = off track_counts = off ... ตามข้อเสนอแนะในhttp://www.postgresql.org/docs/8.4/static/runtime-config-statistics.htm สิ่งนี้ตัดการเขียนอย่างต่อเนื่อง แต่มีข้อเสียใด ๆ ที่ปิดการติดตามสถิติหรือไม่ หรือฉันควรวางไดเรกทอรี pg_stat_tmp บน ramdisk เพื่อหลีกเลี่ยงการรับส่งข้อมูลดิสก์ / เครือข่าย ระบบนี้เป็นเวอร์ชันเดเบียนที่ทันสมัย ​​6.0.7 (บีบ) …

1
ฉันจำเป็นต้อง REINDEX และ VACUUM ตารางหลังจากลบแถวจำนวนมากหรือไม่
ฉันใช้ฐานข้อมูล PostgreSQL ที่มีหลายตารางที่จัดเก็บข้อมูลการบันทึก ข้อมูลนี้มีวัตถุประสงค์เพื่อการรายงานเท่านั้นและถูกเททิ้งไปยังไฟล์และลบออกจากฐานข้อมูลหากเก่ากว่า 30 วัน สามารถลบแถวได้นับล้านแถวและเราได้เรียกใช้ REINDEX ทุกครั้งหลังการลบ มีเพียงพอหรือไม่หรือเราควรใช้การวิเคราะห์สูญญากาศหรือสูญญากาศหรือไม่ หรือดัชนีไม่จำเป็นและเราควรจะแทนเพียงแค่เรียกใช้สูญญากาศหรือสูญญากาศวิเคราะห์? เราใช้ PostgreSQL 8.2.3 ซึ่งฉันเชื่อว่าไม่อนุญาตการดูดฝุ่นอัตโนมัติ
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.