Apakah me-reboot server dalam jadwal merupakan ide bagus untuk kinerja?

Saya bertanya-tanya apakah me-reboot server dalam jadwal akan menjadi ide bagus untuk kinerja.

Katakanlah kita ingin me-reboot server pada jam 02:00 per 2 malam.

Server di sini adalah Windows Server 2008 R2. Terutama, SQL Server dan IIS 7.5 (hampir 15 aplikasi berjalan) berjalan di bawah server ini. Server memiliki memori 4GB.

Sementara saya akan setuju bahwa tidak ada yang salah dengan me-reboot kotak, per se, berdasarkan komentar Anda bahwa SQL Server Agent berhenti, saya akan menyarankan beberapa analisis penyebab root tambahan. Layanan biasanya tidak berhenti begitu saja, dan layanan SQL Server Agent tidak bertindak seperti itu dalam pengalaman saya, biasanya.

Saya pikir Anda akan melakukannya dengan baik, selain dari me-reboot, untuk memeriksa log peristiwa dan menjalankan penghitung log kinerja jangka panjang yang dapat Anda analisis dengan Analisis Kinerja Log (PAL) untuk melihat apakah "melihat" ada yang salah. Anda harus mencoba, jika tidak ada yang lain, untuk mengkorelasikan peristiwa yang terkait dengan Agen SQL yang berhenti dengan faktor lain.

Jika Anda ingin me-reboot komputer untuk meningkatkan kinerja, itu mungkin berarti bahwa pada akhirnya Anda mengalami masalah manajemen memori.

Caching itu Bagus

Jika ada, me-reboot server akan merusak kinerja (dan uptime tentu saja) di lingkungan yang lebih ideal . Salah satu dasar kinerja dalam komputasi adalah untuk mengambil keuntungan dari caching (memiliki data yang tersedia dalam memori cepat). Setiap kali Anda reboot, Anda menerbangkan cache Anda. Ini berlaku untuk SQL server dan IIS. Meskipun Anda mungkin tidak memiliki lingkungan yang ideal, yang berikut ini akan membantu memandu Anda ke opsi yang lebih baik daripada me-reboot server sesuai jadwal.

Kebocoran Memori IIS?

Sekarang Anda menyebutkan bahwa ini adalah IIS 7.5. Meskipun saya merasa tertekan, banyak aplikasi web yang berjalan di IIS 7.5 memiliki kebocoran memori sehingga default di IIS adalah untuk me-restart aplikasi setiap X menit dan mematikannya jika kolam APP idle. Yang ideal adalah memperbaiki kebocoran memori - tetapi jika Anda tidak bisa, Anda dapat menyesuaikan pengaturan ini yang mencakup batas memori dan timer. Anda dapat menggunakan perfmon untuk mengetahui proses w3wp mana yang menggunakan memori. Ini agak menyebalkan tetapi Anda dapat mengikatnya kembali dengan kolam aplikasi %systemroot%\system32\inetsrv\APPCMD list wps.

Memori SQL

Kembali ke caching, SQL akan mengambil memori apa yang bisa. Anda dapat membatasi ini di properti untuk SQL server. Jika Anda tidak membatasi memori dan Anda juga menjalankan IIS pada kotak, ini dapat mulai memperjuangkan kinerja membunuh memori. Artikel yang luar biasa ini membahas secara rinci: Panduan Sysadmin untuk Microsoft SQL Memory .

Keseimbangan

Karena Anda memiliki IIS dan SQL di kotak yang sama, Anda harus menyeimbangkan penggunaan memori mereka. Jika tidak, Anda mungkin mendapatkan memori yang kemungkinan akan digunakan kembali bertukar ke disk - yang merupakan tempat yang mengerikan (Harus ada penghitung perfmon untuk aktivitas swap). Dengan menggunakan pengaturan IIS Recycle dan batas Memori SQL, Anda harus dapat membuat sistem ini stabil. Untuk menyeimbangkan ini, Anda mungkin membutuhkan lebih banyak memori dari 4GB. Juga, jika ini merupakan opsi, saya akan sangat menyarankan menempatkan SQL server pada mesin khusus - itu akan membuat kinerja lebih baik dan sangat menyederhanakan hal-hal.

Saya bukan pendukung me-reboot server sesuai jadwal, terutama bukan sebagai cara menyelesaikan beberapa masalah mendasar. Jika Anda perlu me-reboot server ini untuk menyelesaikan masalah kinerja, maka tindakan yang lebih baik adalah menemukan penyebab masalah dan menyelesaikannya. Mem-boot ulang server pada jadwal reguler hanya mengaburkan masalah mendasar.

Jika Anda mengalami kebocoran memori yang signifikan maka pasti, mengapa tidak - jika tidak, reboot setiap bulan dengan pembaruan.

Jika Anda benar-benar ingin me-reboot server sesuai jadwal (karena kebocoran memori atau pembaruan yang disebutkan di atas atau alasan lain) - mengapa tidak melihat solusi cluster? Pasang server lain secara paralel, kaitkan mereka ke penyeimbang beban (bahkan yang sederhana akan melakukannya) dan Anda dapat mem-boot ulang sebanyak yang Anda inginkan tanpa kehilangan layanan up-time atau khawatir bahwa server tidak akan boot sama sekali dan kamu akan keluar.

Itu bukan ide yang mengerikan , tetapi jika itu hanya 'voodoo', itu mungkin tidak akan banyak membantu Anda.

Namun, ada dua alasan untuk tidak membiarkan ini menjadi akhir dari penyelidikan Anda untuk meningkatkan kinerja Anda.

Salah satunya adalah skalabilitas masa depan. Jika pemadaman Anda adalah hasil pemuatan, sejumlah kueri tertentu, kueri tertentu yang mengenai caching, kompilasi kueri, atau bug pengindeksan btree, atau masalah lain yang saat ini berulang setiap hari, mereka mungkin akan lebih sering terjadi saat memuat meningkat seiring waktu. Gigit itu sejak awal.

Masalah lainnya adalah saya menduga Anda harus menghentikan permintaan masuk dari layanan dependen selama restart. Anda baru saja membuat irama operasional. Setiap kali beberapa tugas sehari-hari perlu dijalankan, tugas itu akan dikaitkan dengan restart Anda. Pada titik tertentu, Anda akan memiliki restart bergulir besar yang memakan waktu enam jam (saya tidak melebih-lebihkan di sini, saya telah melihat itu terjadi di lebih dari satu perusahaan) dan tidak ada yang akan ingat mengapa semuanya harus dihentikan dan dimulai kembali di tengah malam ini.

Rekomendasi saya adalah untuk memantau proses SQL dan restart sesuai kebutuhan. Seperti yang disebutkan oleh poster sebelumnya, SQL tidak memiliki kebocoran memori yang orang pikirkan (dan saya katakan ini sebagai orang yang ada di tim MSSQL pada pertengahan 90-an). Anda ingin server database Anda menggunakan hampir 100% memori dan CPU. Yang kurang dari itu adalah pemborosan sumber daya.

Jika Anda mengalami kebocoran kode dan memori yang ditulis dengan buruk maka reboot mungkin merupakan satu-satunya cara untuk mengembalikan memori yang dialokasikan kembali ke kumpulan. Jika Anda memiliki proses yang terikat memori maka penyegaran kolam ini ke keadaan bersih pasti dapat meningkatkan kinerja .... untuk sementara waktu. Tapi ini benar-benar cara yang buruk untuk menangani masalah kinerja, penyebab sebenarnya harus dipecahkan dan diperbaiki.

Kalau tidak, biarkan berjalan sampai Anda membutuhkan jendela pemeliharaan untuk menerapkan tambalan / aplikasi / mengembalikan data. Ini mungkin saat yang tepat untuk menyarankan seorang insinyur kinerja untuk melihat server yang bersangkutan untuk alasan persisnya / masalah apa yang mendorong ini.

Meskipun tidak jawaban yang lengkap per se , tetapi apakah itu pilihan yang layak untuk menambahkan beberapa RAM ke server? 4GB sedikit lebih rendah untuk mesin IIS / SQL Server. Tergantung apakah itu adalah unit server khusus sebenarnya atau desktop yang ditekan ke dalam layanan, Anda mungkin bisa mendapatkannya 8GB atau lebih dengan biaya yang cukup rendah. Memang, jika itu adalah server mungkin harganya sedikit lebih dari RAM desktop standar tetapi itu akan memberi Anda sedikit lebih banyak waktu antara reboot paksa.

Mengatakan itu, lihat apakah Anda dapat membatasi SQL Server untuk menggunakan maksimum 80% dari RAM, atau melihat log untuk memperbaiki apa yang salah dan / atau mengapa layanan berhenti.

Tidak terkait dengan masalah SQL yang mungkin Anda hadapi jika Anda memiliki server Windows dan mengikuti segala rutinitas penambalan, Anda akan me-reboot server secara teratur tanpa harus me-reboot "hanya karena". Ketika saya bekerja untuk "BIG MULTINATIONAL" kami diberi mandat untuk menambal bulanan dan karena itu semua server kami di-reboot setiap bulan setidaknya sekali.

Saya melakukan ini pada 3 server, 1 adalah pelanggan kami dan 2. Saya telah menyelesaikannya karena berbagai alasan - satu server 2008R1 memiliki banyak pembaruan yang tertunda untuk diinstal, tetapi saya tidak dapat menginstalnya secara batch, jadi saya menginstalnya satu per satu setiap hari; server lain 2012R2 - untuk pemecahan masalah boot dan beberapa masalah kinerja, dll. Saya pikir itu bukan praktik yang buruk untuk menjadwalkan reboot berkala, dari hard lainnya. Dapat membantu melacak berbagai masalah perangkat keras dan perangkat lunak, terutama yang terlibat dalam start otomatis .

Saya tahu perusahaan besar yang tidak hanya me-reboot server Windows mereka setiap malam, tetapi beberapa dari mereka bahkan diinstal ulang setiap 24 jam. Bagi mereka, itu perlu karena leeks memori dalam masalah perangkat lunak dan keamanan.

Tampaknya beberapa perusahaan me-reboot setiap 24 jam - meskipun tampaknya aneh bagi saya sebagai administrator linux. Untuk memperjelas: Saya tidak akan merekomendasikan untuk melakukan ini karena masalah memori - melacak masalah dan menyelesaikannya.

Jika penggunaan memori Anda tetap pada 75% selama berbulan-bulan, maka mungkin tidak perlu melakukan reboot - itu benar-benar normal untuk aplikasi server untuk menggunakan semua memori yang tersedia - itu meningkatkan kinerja banyak karena Anda membutuhkan lebih sedikit disk-IO's jika Anda menggunakan RAM untuk menyimpan data Anda.