Waktu maksimum untuk mana Linux PC bisa UP? [Tutup]


12

Sebenarnya saya punya sistem linux (menjalankan Ubuntu 12.04.3) selama berhari-hari tanpa reboot. Saya berlari ke beberapa kesalahan seperti sleep hang dan beberapa sistem file yang dipasang jaringan tidak mendapatkan mount bahkan dapat melakukan ping (diverifikasi melalui PC lain, jaringan mount berfungsi dengan baik).

Ingin memeriksa apakah Linux juga perlu me-reboot mesin setelah beberapa jangka waktu untuk menghindari jenis kesalahan weired yang tidak dapat diulang.

Berapa lama waktu maksimum kita dapat mempertahankan PC? Adakah masalah lain yang dapat terjadi jika kita memiliki sistem untuk setahun atau lebih tanpa reboot?


2
Saya tidak berpikir ada batasan statis, karena komputer tidak dimaksudkan untuk bangun dan berjalan untuk waktu yang lama. Tidak ada batasan nilai; hanya berapa lama komputer Anda bisa begadang. Mengapa Anda tidak ingin reboot sesekali.
TheWanderer

7
@ Zacharee1 umm, mengapa Anda INGIN reboot? Kecuali konsumsi daya, tidak ada banyak alasan. Sebenarnya, lebih baik jika Anda tidak melakukannya. Perangkat keras umumnya akan bertahan, X tahun per bagian. Mari kita sederhananya mengatakan bahwa X secara universal 10 (itu tidak akan jauh juga) - itu biasanya 10 tahun terus menerus penggunaannya bisa bertahan. Itu penggunaan normal. Jika Anda reboot itu tidak digunakan terus-menerus tetapi Anda juga memukul perangkat keras besar saat mesin boot. Jika Anda biarkan begitu saja - sebagian besar komponen mengalami penurunan, kurangi konsumsi dan pakai pula.
VLAZ

1
Ini jelas bahwa bagian mengalami lebih banyak keausan saat digunakan. Namun, me-reboot (berbeda dari hanya mematikan sistem) tidak mengurangi keausan pada komponen, itu meningkatkannya. Juga, Anda secara mendasar salah paham bagaimana cache bekerja jika Anda berpikir bahwa data yang di-cache dalam RAM memperlambat komputer Anda.
user6053

1
Jika Anda menjalankan server web di Linux (mis. LAMP) Anda ingin menghindari reboot sebanyak mungkin karena hal itu akan membuat situs web Anda down selama waktu yang dibutuhkan sistem untuk kembali naik. Saya tidak berpikir saya pernah pergi setahun tetapi tentu saja beberapa bulan tanpa me-reboot.
tcrosley

2
@ Zacharee1 cukup banyak dalam RAM tidak akan memperlambat komputer Anda. Jika ada kebocoran memori dalam suatu aplikasi, itu bisa mengambil, katakanlah, 60% dari RAM dan sistem akan segera mulai bertukar yang lambat, namun, solusinya adalah me-restart aplikasi, bukan OS. Menghentikan mesin menghentikan keausan komponen tetapi Anda akan menggantinya lebih cepat daripada biasanya dalam kebanyakan kasus. Dan lagi pula, seperti yang saya tunjukkan, komponen perangkat keras sudah mengurangi keausan sendiri. Cukup dengan membiarkan sistem idle.
VLAZ

Jawaban:


36

Bekerja sebagai administrator sistem, saya melihat server Linux untuk lebih dari 700-800 hari tanpa reboot, jadi tidak ada batasan waktu aktif; kesalahan yang Anda dapatkan tidak terkait dengan Linux (kernel) itu sendiri.

Banyak layanan dapat direstart dan sebagian besar kesalahan dapat diselesaikan pada sistem produksi.


7
Dapat mengkonfirmasi ini. Waktu aktif saat ini di salah satu server saya: ~ $ waktu kerja 00:13:15 hingga 883 hari, jam 9:00, 1 pengguna, rata-rata muat: 0,00, 0,01, 0,05 Ubuntu 12,04 LTS. Tidak perlu memperbarui apa pun karena itu tidak menjalankan sesuatu yang penting.
Minthos

5
Saya telah berhasil menyimpan instance Linux tertanam selama 3+ tahun.
Rafał Cieślak

16

Tidak ada kebutuhan teknis untuk me-restart komputer Anda setelah periode waktu tertentu. Saya sudah menjalankan tambang selama berbulan-bulan (termasuk pembaruan modul kernel) dengan beberapa suspensi (ke RAM dan disk) di antaranya.

Ada saat dimana

  • itu benar-benar diperlukan untuk reboot, seperti pembaruan kernel (tetapi itu tidak mendesak dalam banyak situasi, dan dalam beberapa kasus Anda dapat mengganti kernel yang berjalan dengan yang baru pada sistem live. Lihat kexec dan Ksplice )
  • mungkin lebih mudah untuk me-restart seluruh sistem daripada hanya subsistem (set) tertentu.

Mungkin ada beberapa masalah yang “menjadi lebih buruk” dari waktu ke waktu (mis. Masalah driver perangkat keras, proses bocor), tetapi itu dianggap sebagai bug dan seringkali dapat diperbaiki dengan pemutakhiran perangkat lunak atau ditangani dengan memuat ulang / memulai kembali subsistem tertentu (juga Lihat di atas).


6
On the fly kernel patching mendapatkan lebih banyak sensasi daripada yang layak. Sangat bagus jika Anda memiliki waktu untuk memverifikasi bahwa pembaruan akan bekerja seperti itu, tetapi setiap perubahan kode yang membuat struktur data dalam memori berbeda tidak bisa hanya ditambal langsung. Ini tidak akan memungkinkan peningkatan tanpa boot ulang ke kernel baru secara umum. Ini akan memungkinkan perbaikan tanpa boot untuk hal-hal seperti bug yang memeriksa izin. Ini HEBAT, dan luar biasa karena tidak perlu me-reboot server, tetapi jangan berharap ini akan memberi Anda upgrade bebas-reboot ke versi baru.
Peter Cordes

1
Saya setuju dengan Peter. Itu sebabnya saya tidak menyebutkan tambalan langsung dalam konteks ini untuk tidak membuat hal-hal lebih rumit; sayangnya seseorang mengedit jawaban saya.
David Foerster

7

Meskipun saya yakin ada server dengan waktu aktif yang lebih tinggi, saya menyajikan yang berikut dari salah satu server saya sebagai contoh apa yang mungkin:

# uptime
04:58:44 up 2186 days, 23:15,  1 user,  load average: 0.02, 0.02, 0.00

Server ini dipasang tidak lama setelah DC masuk dan tidak dimatikan sejak saat itu. Sejauh ini ia terus dengan senang melakukan apa yang semula dimaksudkan untuk dan ketika tujuan itu dipindahkan ke server yang berbeda saya akan meletakkan sesuatu di sana hanya untuk memantau uptime dan mungkin akan tetap terjaga sampai saya tidak dapat membenarkan menjaganya tetap hidup lebih lama lagi.

Jadi saya pikir "Tidak ada yang maksimal" adalah jawaban yang pasti.


7

Saya tidak tahu apakah ini berdampak pada stabilitas sistem, tetapi uptime maksimum yang ditunjukkan di Ubuntu dengan kernel 3.19-xx adalah 68,0962597349822tahun pada mesin 32-bit dan292471208677,8627 tahun pada mesin 64-bit.

Itu karena uptime sistem saat ini, yang dikembalikan oleh sysinfo()syscall, dikembalikan sebagai __kernel_long_ttipe , yang dinyatakan sebagai longkernel 32-bit dan sebagai kernel 64-bitlong long ;

A longpada mesin 32-bit memiliki nilai maksimum2147483647 ;

A long longpada mesin 64-bit memiliki nilai maksimum 9223372036854775807;

Melakukan matematika, 2147483647s= 68,0962597349822tahun dan 9223372036854775807s=292471208677,8627 tahun.

Setelah nilai ini meningkat melebihi kemampuan tipenya, terjadi overflow aritmatika dan disetel ke nilai terkecil yang diizinkan oleh tipenya (dalam kedua kasus angka negatif): ini mungkin menjadi masalah bagi program yang mengandalkannya.


3
OP tidak meminta uptime maksimum yang dapat dicatat oleh sistem dengan akurat, ia bertanya apakah ia perlu me-reboot sistemnya secara teratur karena stabilitas / etc. batasan.
Boluc Papuccuoglu

@BolucPapuccuoglu Lihat apakah menurut Anda lebih cocok dalam format ini, terutama bagian terakhir. Saya menunjukkan secara eksplisit apa masalahnya. Jika Anda masih berpikir itu tidak, saya akan menghapus jawaban saya.
kos

6

Saya pernah berada di kelas dengan sysadmin yang mengklaim dia memiliki server linux yang berjalan tanpa reboot selama lebih dari satu dekade. Tidak ada alasan inheren sistem perlu di-reboot secara teratur. Ini hanya diperlukan dalam kasus terbatas seperti pembaruan kernel.

FWIW, saya biasanya membiarkan komputer rumah Windows saya berjalan. Biasanya akan berjalan dengan baik selama berminggu-minggu tanpa me-reboot.


Jika komputer Windows Anda berjalan selama berminggu-minggu tanpa me-reboot, Anda jelas tidak memiliki pembaruan otomatis yang diaktifkan. Mereka biasanya diunduh setiap minggu dan hampir selalu menghasilkan reboot.
tcrosley

@tcrosley Lagi pula siapa yang butuh pembaruan otomatis? Itu salah satu hal pertama yang saya matikan pada mesin-mesin itu. Saya akan memutuskan bagaimana menggunakan komputer saya, bukan layanan otomatis.
Tiang

@ tcrosley Apakah Anda yakin pembaruan keamanan Windows biasanya diunduh setiap minggu? Pemahaman saya, baik dari kebijakan rilis pembaruan Microsoft dan dari pengalaman pribadi menggunakan Windows, adalah bahwa pembaruan biasanya dirilis sekitar sebulan sekali. Mast: Meskipun Anda tentu saja bebas untuk menonaktifkan pembaruan otomatis, saya tidak tahu mengapa itu akan menghasilkan waktu yang lebih lama. Agaknya - semoga! - Anda memperbarui secara manual, setidaknya untuk perbaikan keamanan. Di sisi lain, menonaktifkan pembaruan otomatis dapat membuatnya lebih mudah untuk dikontrol ketika downtime terjadi.
Eliah Kagan

@EliahKagan Saya memiliki pengaturan mesin untuk mengunduh tidak hanya perbaikan keamanan, tetapi juga pembaruan aplikasi, driver, dll. Saya mungkin keliru jika seminggu sekali, tetapi tentu saja lebih sering daripada sebulan sekali. Ia memeriksa pembaruan setiap pagi pada jam 3:00 pagi. Saya akan datang di pagi hari, dan menemukan sistem saya telah reboot, dan setelah masuk, ada pesan "Sistem Anda telah reboot untuk menginstal pembaruan."
tcrosley

4

Linux (kernel) sangat bagus dalam membebaskan sumber daya ketika program keluar. GNU / Linux, seluruh OS, umumnya baik untuk berjalan tanpa batas. Restart program ruang pengguna setelah Anda memperbaruinya umumnya adalah ide yang bagus, dan seringkali cara termudah untuk mendapatkan semuanya menggunakan pembaruanglibc adalah dengan mem-boot ulang sistem.

Pada sistem dengan bug driver (biasanya bug driver grafis, yang lainnya biasanya solid), Anda terkadang mendapatkan perilaku aneh yang semakin aneh jika Anda tidak segera reboot. Jika Anda melihat kernel OOPS di dmesgoutput Anda, Anda harus reboot segera jika nyaman, dan melaporkannya (atau google sekitar untuk orang lain dengan masalah yang sama pada perangkat keras yang sama, jika itu masalah yang diketahui). Distro tidak mengirimkan versi terbaru dari tumpukan grafik, jadi terkadang bug sudah diperbaiki di bagian hulu, dan kartu grafis Anda terlalu baru untuk driver pada versi distro yang Anda jalankan menjadi stabil. Dalam hal ini, cari PPA dengan versi terbaru dari mesa / drm / xorg. (Saya tidak yakin apa pilihan terbaik untuk menjalankan Ubuntu dengan tumpukan grafik yang berdarah adalah ATM).

Bagaimanapun, kecuali driver atau bug kernel lainnya, Linux dapat berjalan tanpa batas tanpa perlu reboot untuk menghapus fragmentasi memori atau hal-hal seperti itu.

Saya memiliki router Linux / firewall / mailserver / shell box (P3 450MHz, OCed hingga 500MHz) yang secara rutin melihat waktu ratusan hari. Saya reboot hanya untuk mengatur ulang kabel daya, atau untuk mengganti catu daya yang gagal. Sudah stabil dengan CPU / RAM / hard drive yang sama selama mungkin 15 tahun. Saya tidak pernah harus me-reboot "karena semakin tidak stabil". Itu selalu karena alasan tertentu, seperti kegagalan pasokan listrik, atau peningkatan kernel, atau pemadaman listrik dan baterai UPS saya hampir habis (memicu auto shutdown with apcupsd).

Jika sistem Anda bertingkah aneh, periksa dmesgmasalahnya. Jika itu hanya desktop Anda, maka jika Anda baru saja menginstal beberapa pembaruan paket non-kernel, logout / login (atau reboot, tetapi Anda tidak harus melakukannya). Saya telah menemukan Kubuntu 15.04 akan dengan mudah mengalami masalah setelah pembaruan paket, saya pikir karena ketidakcocokan biner antara versi yang ditingkatkan / tidak ditingkatkan dari perpustakaan yang sama yang berjalan dalam biner yang sama. (Lihat diskusi tentang bug ini ).

Tujuan saya untuk memeriksa masalah perangkat keras adalah untuk boot memtest86 +. ( aptitude install memtest86+) Biarkan itu menjalankan operan penuh, atau jalankan semalaman. Itu tidak menjamin sistem yang stabil, karena penurunan tegangan listrik pada beban spike dapat terjadi dengan CPU hari ini, dan memtest tidak akan mengesampingkan hal itu. CPU Anda tidak akan panas, seperti Prime95.


3

Mesin saya hanya restart hari ini untuk 15,04 setelah 11 hari tanpa kesalahan aneh yang dapat saya ingat. Jika Anda melakukan pekerjaan berat dan pengembangan pada suatu sistem, itu kadang-kadang bisa menjadi satu-satunya pilihan untuk reboot, tetapi itu hanya berdasarkan kebutuhan saja.


Anda benar! Saya telah mengembangkan 16,04 selama beberapa bulan. Karena pembekuan saya me-restart komputer saya umumnya setiap hari. Tapi saya yakin alasannya adalah apa yang saya instal dan saya gunakan dan driver dll.
efkan

1

Secara teknis tidak ada batasan. Anda hanya perlu mengaturnya agar tidak tidur atau mati.


3
Bisakah Anda menjelaskan dan menguraikan jawaban Anda lebih lanjut? Khususnya baris ini you just have to set it to not sleep or shut down.
heemayl

"Secara teknis tidak ada batasan" sudah cukup sebagai jawaban singkat, singkat dan benar.
Léo Lam

0

Secara pribadi saya tidak ingin menjalankan laptop atau PC saya selama berhari-hari tanpa me-reboot atau mematikannya.

Hanya karena komponen utama yang menghasilkan panas dapat mempercepat keausan pada MB.

(Itu jika Anda tidak memiliki pendingin dan ventilasi yang tepat)


4
Jika ini sampah kelas konsumen seperti Acer atau HP, tetapi Thinkpads tingkat bisnis atau laptop Dell Latitude biasanya dibuat lebih baik; Saya pribadi memiliki Latitude yang berjalan 24x7 selama lebih dari satu tahun sekarang, tepat di sebelah saya dan masih berfungsi dengan baik.

@kingtoor Mengapa lebih baik menjalankan mesin 24x7 yang tidak cukup dingin dengan reboot sesekali daripada menjalankannya 24/7 tanpa reboot? (Atau bukan itu yang ingin Anda katakan?)
Eliah Kagan

1
Mematikan / tidur saat tidak digunakan pada laptop yang menjadi panas saat dibiarkan 24/7, ok tentu. Itu tidak terkait dengan mem-boot ulang (tanpa menghabiskan waktu) vs uptime terus-menerus.
Peter Cordes

Jawaban saya ada di komentar saya.
Kingtoor

Juga saya tidak benar-benar melihat alasan untuk pengguna biasa menjalankan pc mereka 24/7 kecuali mereka memiliki server. Itulah pendapat saya.
Kingtoor

0

Tidak khusus untuk Ubuntu, tapi saya punya laptop vintage 1997 (300 MHz, 288 MB RAM) menjalankan distro berbasis Debian yang telah uptime hingga 60 hari, sambil menjalankan satu program (ditambah hal-hal sistem dan conky) dan tidak memulai dan menghentikan perangkat lunak lain kecuali terminal untuk memuat pembaruan setiap minggu. Akhirnya, crash ketika memuat pembaruan, sekitar 63 hari. Sebaliknya, sistem desktop Kubuntu 14.04 saya akan membeku di kunci layar setelah sekitar dua minggu. Saya setuju dengan jawaban lain; ini lebih tentang perangkat lunak apa yang Anda jalankan dan seberapa sering Anda memulai dan menghentikan program lain, daripada tentang Linux.


Jika crash (maksud saya hard crash atau freeze, bukan hanya X crashing yang dapat diperbaiki tanpa me-reboot), itu mungkin berarti ada masalah perangkat keras (overheating, RAM buruk, dll). Sebagai sysadmin saya kadang-kadang server saya berjalan selama berbulan-bulan tanpa me-reboot, meskipun saya lebih suka menghindarinya karena Anda harus reboot untuk menerapkan pembaruan kernel.

Ketika kunci layar telah menjadi layar hitam, tidak ada cara yang efektif untuk mengetahui apakah itu kunci sistem keras atau kegagalan server X - dan tidak ada cara untuk mengakses baris perintah (tanpa kemampuan untuk memasukkan kata sandi) untuk memulai kembali X atau apa pun mungkin. Saya cenderung berpikir jika dibutuhkan dua minggu, ini bukan RAM yang terlalu panas atau buruk.
Zeiss Ikon

Ctrl + Alt + F1 tidak berfungsi? Dan driver grafis yang buruk mungkin pelakunya - mereka mungkin belum diuji dengan uptime tinggi dalam pikiran, tetapi Linux pasti dapat berjalan selama bertahun-tahun tanpa masalah.

Saya harus mencoba CTL-ALT-F1, jika saya dapat mengingatnya lain kali saya mendapatkan pembekuan kunci layar (saya telah menggunakan hard reset). Saya kira saya akan gunakan startxuntuk me-restart server X? Atau apakah saya perlu menggunakan perintah khusus untuk memulai kembali layanan? Saya sangat menyadari pepatah lama Linux, bahwa "Restart adalah untuk peningkatan kernel dan instalasi perangkat keras."
Zeiss Ikon

Masuk sebagai root atau sebagai pengguna biasa dan gunakan sudo, dan ikuti petunjuk ini
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.