การรีบูตเซิร์ฟเวอร์ตามกำหนดเวลาเป็นความคิดที่ดีสำหรับประสิทธิภาพหรือไม่

ฉันสงสัยว่าการรีบูตเซิร์ฟเวอร์ตามกำหนดเวลาเป็นความคิดที่ดีสำหรับประสิทธิภาพหรือไม่

สมมติว่าเราต้องการรีบูตเซิร์ฟเวอร์เวลา 02:00 น. ต่อ 2 คืน

Windows Server 2008 R2เซิร์ฟเวอร์ที่นี่คือ ส่วนใหญ่แล้ว SQL Server และ IIS 7.5 (เกือบ 15 แอพที่รัน) กำลังทำงานภายใต้เซิร์ฟเวอร์นี้ เซิร์ฟเวอร์มีหน่วยความจำ 4GB

ในขณะที่ฉันจะยอมรับว่าไม่มีอะไรผิดปกติกับการรีบูตกล่องตามความคิดเห็นของคุณว่า บริษัท ตัวแทนของเซิร์ฟเวอร์ SQL กำลังหยุดฉันจะแนะนำการวิเคราะห์สาเหตุรากเพิ่มเติมบางอย่าง โดยทั่วไปแล้วบริการจะไม่หยุดเพียงแค่นั้นและบริการตัวแทนของเซิร์ฟเวอร์ SQL ไม่ได้ทำแบบนั้นในประสบการณ์ของฉัน

ฉันคิดว่าคุณทำได้ดีนอกเหนือจากการรีบูตเครื่องเพื่อตรวจสอบบันทึกเหตุการณ์และเรียกใช้ตัวนับประสิทธิภาพการทำงานระยะยาวที่คุณสามารถวิเคราะห์ด้วยPerformance Analysis of Logs (PAL) เพื่อดูว่ามีอะไรผิดปกติหรือไม่ คุณควรลองเชื่อมโยงเหตุการณ์ที่เกี่ยวข้องกับ SQL Agent เพื่อหยุดสัมพันธ์กับปัจจัยอื่น ๆ

หากคุณต้องการรีบูตเครื่องคอมพิวเตอร์เพื่อปรับปรุงประสิทธิภาพอาจเป็นได้ว่าในที่สุดคุณกำลังประสบปัญหาการจัดการหน่วยความจำ

แคชเป็นสิ่งที่ดี

หากมีสิ่งใดการรีบูตเซิร์ฟเวอร์อาจส่งผลเสียต่อประสิทธิภาพ (และเวลาที่แน่นอน) ในสภาพแวดล้อมที่เหมาะสมยิ่งขึ้น หนึ่งในพื้นฐานของประสิทธิภาพในการคำนวณคือการใช้ประโยชน์จากแคช (มีข้อมูลอยู่ในหน่วยความจำเร็ว) ทุกครั้งที่คุณรีบู๊ตคุณจะล้างแคชของคุณ นี่เป็นเรื่องจริงสำหรับทั้งเซิร์ฟเวอร์ SQL และ IIS แม้ว่าคุณอาจไม่ได้มีสภาพแวดล้อมที่เหมาะสม แต่สิ่งต่อไปนี้ควรช่วยแนะนำให้คุณเลือกตัวเลือกที่ดีกว่าการรีบูทเซิร์ฟเวอร์ตามกำหนดเวลา

การรั่วไหลของหน่วยความจำ IIS?

ตอนนี้คุณพูดถึงว่านี่คือ IIS 7.5 แม้ว่าฉันจะพบว่ามันน่าหดหู่ใจเว็บแอปมากมายที่ทำงานบน IIS 7.5 มีหน่วยความจำรั่วที่ค่าเริ่มต้นใน IIS คือการรีสตาร์ทแอปทุก ๆ X นาทีและปิดลงหากแอพว่าง อุดมคติคือการแก้ไขการรั่วไหลของหน่วยความจำ - แต่ถ้าคุณทำไม่ได้คุณอาจปรับการตั้งค่าเหล่านี้ซึ่งรวมถึงการ จำกัด หน่วยความจำและตัวจับเวลา คุณสามารถใช้ perfmon เพื่อหาว่ากระบวนการ w3wp ใดกำลังใช้หน่วยความจำ มันเป็นบิตของความเจ็บปวด แต่คุณสามารถผูกมันกลับมาว่ายน้ำใน app %systemroot%\system32\inetsrv\APPCMD list wpsกับ

หน่วยความจำ SQL

กลับไปสู่การแคช SQL จะใช้หน่วยความจำเท่าที่จะทำได้ คุณสามารถ จำกัด สิ่งนี้ได้ในคุณสมบัติสำหรับเซิร์ฟเวอร์ SQL ถ้าคุณไม่ จำกัด หน่วยความจำและคุณกำลังเรียกใช้ IIS บนกล่องสิ่งเหล่านี้สามารถเริ่มต่อสู้เพื่อประสิทธิภาพการฆ่าหน่วยความจำ บทความนี้จะเข้าสู่ที่ยอดเยี่ยมนี้ในรายละเอียด: คู่มือการดูแลระบบของหน่วยความจำไปยัง Microsoft SQL

สมดุล

เนื่องจากคุณมีทั้ง IIS และ SQL ในกล่องเดียวกันคุณจะต้องปรับสมดุลการใช้หน่วยความจำ หากคุณไม่ทำเช่นนั้นคุณอาจได้รับหน่วยความจำที่น่าจะถูกนำไปใช้สลับกับดิสก์อีกครั้งซึ่งเป็นสถานที่ที่น่ากลัว (ควรมีเคาน์เตอร์สำหรับการแลกเปลี่ยนกิจกรรม) โดยใช้การตั้งค่า IIS Recycle และขีด จำกัด หน่วยความจำ SQL คุณควรจะสามารถทำให้ระบบนี้มีเสถียรภาพ เพื่อความสมดุลคุณอาจต้องใช้หน่วยความจำมากกว่า 4GB นอกจากนี้หากเป็นตัวเลือกฉันขอแนะนำอย่างยิ่งให้วางเซิร์ฟเวอร์ SQL ไว้ในเครื่องเฉพาะ - มันจะทำให้ประสิทธิภาพดีขึ้นและทำให้สิ่งต่าง ๆ ง่ายขึ้นอย่างมาก

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

หากคุณมีการรั่วไหลของหน่วยความจำอย่างมีนัยสำคัญแน่นอนว่าทำไมไม่ - มิฉะนั้นรีบูตทุกเดือนด้วยการปรับปรุง

หากคุณต้องการรีบูทเซิร์ฟเวอร์ตามกำหนดเวลาจริง ๆ (เนื่องจากหน่วยความจำรั่วไหลหรืออัพเดตหรือเหตุผลอื่น ๆ ) - ทำไมไม่ลองดูที่วิธีแก้ปัญหาแบบคลัสเตอร์ วางเซิร์ฟเวอร์อื่นในแบบคู่ขนานเชื่อมต่อกับ load balancer (แม้แต่เซิร์ฟเวอร์ธรรมดาก็ทำได้) และคุณสามารถรีบูตเซิร์ฟเวอร์ได้มากเท่าที่คุณต้องการโดยไม่เสียเวลาให้บริการหรือกังวลว่าเซิร์ฟเวอร์จะไม่บู๊ตเลย คุณจะออกไป

มันไม่ใช่ความคิดที่น่ากลัวแต่ถ้าเป็นเพียง 'วูดู' มันอาจจะไม่ช่วยคุณเท่าไหร่

อย่างไรก็ตามมีเหตุผลสองประการที่จะไม่ปล่อยให้เรื่องนี้สิ้นสุดการสอบสวนเพื่อปรับปรุงประสิทธิภาพของคุณ

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

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

คำแนะนำของฉันคือการตรวจสอบกระบวนการ SQL และเริ่มใหม่ตามต้องการ ตามที่กล่าวไว้โดยผู้โพสต์ก่อนหน้านี้ SQL ไม่ได้มีหน่วยความจำรั่วที่คนคิดว่ามันทำ (และฉันพูดแบบนี้ว่าเป็นคนที่อยู่ในทีม MSSQL ในช่วงกลางยุค 90) คุณต้องการให้เซิร์ฟเวอร์ฐานข้อมูลของคุณใช้หน่วยความจำและ CPU เกือบ 100% สิ่งที่น้อยกว่าคือการสูญเสียทรัพยากร

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

มิฉะนั้นปล่อยให้มันรันจนกว่าคุณต้องการหน้าต่างการบำรุงรักษาเพื่อใช้แพตช์ / แอปพลิเคชัน / กู้คืนข้อมูล นี่อาจเป็นเวลาที่ดีที่จะแนะนำวิศวกรด้านประสิทธิภาพให้ตรวจสอบเซิร์ฟเวอร์ที่มีปัญหาว่าอะไรเป็นสาเหตุที่ทำให้เกิดปัญหา

ในขณะที่ไม่ได้เป็นคำตอบที่สมบูรณ์ต่อ seแต่มันก็เป็นตัวเลือกที่ทำงานเพื่อเพิ่มบาง RAM เพิ่มลงในเซิร์ฟเวอร์หรือไม่ 4GB นั้นค่อนข้างต่ำสำหรับเครื่อง IIS / SQL Server ขึ้นอยู่กับว่าเป็นหน่วยเซิร์ฟเวอร์เฉพาะจริงหรือเดสก์ท็อปที่ให้บริการคุณอาจได้รับ 8GB หรือมากกว่านั้นในราคาที่ค่อนข้างต่ำ จริงอยู่ถ้ามันเป็นเซิร์ฟเวอร์มันอาจเสียค่าใช้จ่ายมากกว่า RAM บนเดสก์ท็อปเล็กน้อย แต่มันจะทำให้คุณมีเวลามากขึ้นเล็กน้อยระหว่างการรีบูตแบบบังคับ

สมมติว่าให้ดูว่าคุณสามารถ จำกัด SQL Server ให้ใช้ RAM สูงสุดได้ถึง 80% หรือดูบันทึกเพื่อปรับสิ่งที่ผิดพลาดและ / หรือสาเหตุที่บริการหยุดทำงาน

ไม่เกี่ยวข้องกับปัญหา SQL ที่คุณอาจต้องเผชิญหากคุณมีเซิร์ฟเวอร์ Windows และกำลังทำตามขั้นตอนการแพ็ตช์ใด ๆ คุณจะต้องรีบูทเซิร์ฟเวอร์เป็นประจำโดยไม่ต้องรีบูต "เพียงเพราะ" เมื่อฉันทำงานกับ "Big MULTINATIONAL" เราได้รับคำสั่งให้แก้ไขรายเดือนและทำให้เซิร์ฟเวอร์ของเราทั้งหมดถูกรีบูทเป็นประจำทุกเดือนอย่างน้อยหนึ่งครั้ง

ฉันทำสิ่งนี้บน 3 เซิร์ฟเวอร์ 1 คือลูกค้าของเราและ 2 คน ฉันได้ตั้งค่าด้วยเหตุผลต่าง ๆ - เซิร์ฟเวอร์หนึ่ง 2008R1 มีการอัปเดตจำนวนมากรอการติดตั้ง แต่ฉันไม่สามารถแบตช์ติดตั้งได้ดังนั้นฉันจึงติดตั้งทีละตัวทุกวัน เซิร์ฟเวอร์อื่น 2012R2 - สำหรับการแก้ไขปัญหาการบู๊ตและปัญหาด้านประสิทธิภาพ ฯลฯ ฉันไม่คิดว่ามันเป็นวิธีปฏิบัติที่ไม่ดีในการกำหนดเวลาการรีบูตเป็นระยะจากฮาร์ดไดรฟ์อื่น ๆ มันสามารถช่วยติดตามปัญหาฮาร์ดแวร์และซอฟต์แวร์ต่าง ๆ โดยเฉพาะอย่างยิ่ง .

ฉันรู้ว่าเป็น บริษัท ใหญ่ที่ไม่เพียง แต่รีบูตเซิร์ฟเวอร์ Windows ของพวกเขาทุกคืน แต่พวกเขาบางคนยังได้รับการติดตั้งใหม่ทุก 24 ชั่วโมง สำหรับพวกเขามันจำเป็นเพราะหน่วยความจำในซอฟต์แวร์และปัญหาด้านความปลอดภัย

ดูเหมือนว่าบาง บริษัท กำลังทำการรีบูตทุก ๆ 24 ชั่วโมง - แม้ว่าฉันจะรู้สึกแปลก ๆ ในฐานะผู้ดูแลระบบลินุกซ์ เพื่อให้ชัดเจน: ฉันจะไม่แนะนำให้ทำเช่นนี้เพราะปัญหาหน่วยความจำ - ติดตามปัญหาและแก้ไข

หากการใช้หน่วยความจำของคุณคงที่ที่ 75% ต่อเดือนอาจไม่จำเป็นต้องรีบูต - มันเป็นเรื่องปกติสำหรับแอปพลิเคชันเซิร์ฟเวอร์ที่จะใช้หน่วยความจำทั้งหมดที่มี - มันช่วยเพิ่มประสิทธิภาพได้มากเพราะคุณต้องการดิสก์ - IO น้อยลง RAM เพื่อแคชข้อมูลของคุณ