Re: Πολύ συχνό 100% CPU και HDD

Konstantinos Togias ktogias at gmail.com
Tue Jul 28 09:45:52 UTC 2015


4 giga είναι λίγα πολύ λίγα
6 giga είναι λίγα, τι να πω,
8 giga είναι λίγα, πολύ λίγα,
δώσε μου 16 και swap δεν θα ξαναχρειαστώ.

Δωσ' μου πολλά giga ram, αμέτρητα, τρελά,
κι εγώ αχρείαστη θα έχω τη swap μου,
μη τσιγγουνεύεσαι, πάντα να σκέφτεσαι
πως η ram πάντα βοηθά

(Παράφραση από το υπέροχο τραγουδάκι που λέει με μοναδικό τρόπο ο
Κηλαηδόνης -  http://www.stixoi.info/stixoi.php?info=Lyrics&act=details&song_id=41116
)

Δυστυχώς για τις σημερινές εφαρμογές και κυρίως το web τα 4 GB ram δεν
επαρκούν για μέτρια προς βαριά χρήση desktop. Για web development που
είναι η δουλειά μου, με ένα firefox (5-6 καρτέλες ανοιχτές), ένα
chrome (2-3 καρτέλες ανοιχτές) και ένα ide (netbeans) ανοιχτά, ήδη τα
4GB είναι σχεδόν τίγκα. Αν χρειαστεί να ανοίξω και μια τρίτη σχετικά
βαριά εφαρμογή (π.χ. κάποιο πρόγραμμα διαχείρισης βάσεων δεδομένων -
valentina studio, mysql workbench, oracle sql developer ή για
επεξεργασία γραφικών - gimp, inkscape κλπ) με 4GB RAM δεν το γλιτώνω
το swapping και τις καθυστερήσεις που αυτό συνεπάγεται. Το να έχεις το
swap σε ssd δίσκο βοηθάει σε αυτό το σημείο αρκετά ελαχιστοποιώντας
τις καθυστερήσεις.

Το πρόβλημα του Εμμανουήλ, το είχα αντιμετωπίσει ακριβώς το ίδιο σε
ένα laptop με ssd και 4GB RAM όπου είχα τη φαεινή ιδέα να
απενεργοποιήσω το swap και καλά για να μην φθείρω τον ssd, και
θεωρώντας ότι τα 4GB είναι αρκετά. Είχα φυσικά ρυθμίσει και το
swappiness σε μια πολύ χαμηλή τιμή. Λίγο αφού άνοιγα 2-3 από τις
εφαρμογές που αναφέρω παραπάνω το σύστημα γινόταν μη αποκρίσιμο με τον
ssd να κάνει διαρκώς reads. Αν το περίμενα κάποια λεπτά ο πυρήνας
αποφάσιζε να σκοτώσει κάποια από τις μεγάλες εφαρμογές, οπότε το
σύστημα επανερχόταν. Παρόμοια συμπεριφορά είχα και όταν πειραματίστηκα
με πολύ μικρό swap partition στο ίδιο μηχάνημα (200MB).

Χωρίς να το έχω ψάξει διεξοδικά, νομίζω ότι ο λόγος που γίνονται τόσο
άσχημα τα πράγματα όταν δεν επαρκεί η RAM και δεν έχεις -αρκετό- swap
είναι το caching. Αν κάνουμε ένα free -m θα δούμε ότι ένα μεγάλο μέρος
της RAM χρησιμοποιείται για   buffer/cache (αυτή τη στιγμή στο pc μου
με 4G RAM έχω 1509ΜΒ buff/cache). Για το τι είναι το cache δείτε εδώ:
http://www.linuxatemyram.com/ . Ουσιαστικά cachaρει πράγματα από το
δίσκο (βιβλιοθήκες, αρχεία κλπ) στη RAM προκειμένου οι εφαρμογές να
τρέχουν γρηγορότερα και το σύστημα να είναι αποκρίσιμο.  Αν και στο
άρθρο που παρέθεσα πιο πριν λέει ότι το disk caching disk δανείζεται
μόνο ram που δεν χρειάζονται οι εφαρμογές που τρέχουν και ότι αν οι
εφαρμογές χρειαστούν παραπάνω μνήμη θα την πάρουνε από την cache πριν
αρχίσουν να swapάρουν, τα πράγματα όταν υπάρχει swap φαίνεται να μην
είναι ακριβώς έτσι. Π.χ. στο σύστημά μου  (4GB RAM) πριν λίγο είχα

2175 ΜΒ used, 1509 ΜΒ buff/cache, 367ΜΒ Swap, 138ΜΒ free και 787MB available
- στα available περιέχεται και κάποια από την cache που μπορεί να
αποδοθεί άμεσα εφόσον ζητηθεί από κάποια εφαρμογή - το πως αθροίζονται
τα νούμερα και γιατί το available δεν είναι ίσο με free+cache, αλλά
λιγότερο, το έχω απορία και εγώ. Αν κάποιος ξέρει παραπάνω ας μας
διαφωτίσει.

Ανοίγοντας κάποιες βαριές εφαρμογές η κατάσταση διαμορφώνεται ως εξής:
2873 ΜΒ used, 829ΜΒ buff/cache, 674ΜΒ Swap, 121ΜΒ free και 212MB available

Ο πυρήνας φαίνεται να προτιμά να πετάξει στη swap κάποια πράγματα
(μνήμη εφαρμογών) που πρέπει να είναι φορτωμένα αλλά δεν
χρησιμοποιούνται συχνά (π.χ. μια αδρανής εφαρμογή στο παρασκήνιο ή
κάποιες βιβλιοθήκες που δεν χρησιμοποιούνται αυτή τη στιγμή από κάποια
εφαρμογή ) και να κρατήσει κάποιο χώρο στη RAM για cache. Όσο έχει
χώρο στη swap θα κατεβάζει εκεί μνήμη εφαρμογών που δεν
χρησιμοποιείται και έτσι θα εξασφαλίζει κάποια ελάχιστα MB για να
cachάρει δεδομένα από το δίσκο που χρειάζονται οι εφαρμογές που
τρέχουν κάθε στιγμή.

Τι γίνεται λοιπόν όταν δεν έχουμε καθόλου swap ή είναι πολύ λίγο;  Μην
μπορώντας να πετάξει πράγματα που δεν χρησιμοποιούνται κάθε στιγμή
στην swap, αναγκάζεται να έχει όλη τη μνήμη όλων των εφαρμογών που
είναι ανοικτές στη RAM. Έτσι δεν μένει καθόλου χώρος για cache. Κάθε
εφαρμογή που χρειάζεται να διαβάσει κάτι που είναι στο δίσκο θα πρέπει
να το φέρει κάνοντας io στο δίσκο. Και αν το χρειαστεί ξανά μετά από
λίγα δευτερόλεπτα θα πρέπει να κάνει πάλι io στο δίσκο. Και όταν
έχουμε περίπλοκες εφαρμογές όπως web browsers ή ides που διαρκώς
θέλουν πληροφορίες από το δίσκο ( τη δική τους cache ;) ) η ανάγκη να
προσπελάσει η εφαρμογή που τρέχει κάποια δεδομένα από το δίσκο είναι
πολύ πιο συχνή από την ανάγκη να έρθει μια αδρανής εφαρμογή από το
swap όπου έχει αράξει στη RAM.

Αυτός υποθέτω είναι και ο λόγος που βλέπουμε το λαμπάκι του δίσκου να
είναι συνέχεια αναμένο και το σύστημα να μην αποκρίνεται καθόλου στην
περίπτωση που δεν έχουμε -αρκετή- swap. Ότι χρειάζεται από το δίσκο
πρέπει να έρθει από το δίσκο... κάθε φορά... και αυτό είναι πολύ πολύ
αργό. Ενώ όταν έχουμε αρκετό χώρο swap, μπορεί να έχουμε καθυστερήσεις
στις εναλλαγές μεταξύ εφαρμογών (όταν ενεργοποιούμε κάποια εφαρμογή η
μνήμη που απασχολεί πρέπει να μεταφερθεί τη swap στη RAM και αν δεν
υπάρχει αρκετός χώρος, η μνήμη κάποιας άλλης εφαρμογής που είναι πλέον
αδρανής να μεταφερθεί στο swap), αλλά η εφαρμογές που εκτελούνται κάθε
στιγμή και οι βασικές λειτουργίες του συστήματος παραμένουν σε μεγάλο
βαθμό αποκρίσιμες, μια και μπορούν να επωφελούνται από ένα ελάχιστο
έστω disk caching.

Έχοντας τα παραπάνω στο νου, έχω καταλήξει ότι με το σημερινό
λογισμικό, μέχρι και τα 8GB RAM χρειάζεται οπωσδήποτε swap. Εμπειρικά,
μέχρι τα 4GB RAM το μέγεθος του swap partition πρέπει να είναι
τουλάχιστο όσο και η RAM για να μην έχουμε προβλήματα. Από τα 8GB RAM
και πάνω, με τα σημερινά δεδομένα, σε χρήση desktop, σπάνια θα
χρειαστεί swap το σύστημα, και όταν χρειαστεί θα είναι σχετικά λίγη
(το πολύ λίγες εκατοντάδες MB). Εξάλλου μετά τα 2-3 GB
χρησιμοποιούμενη swap σε χρήση desktop, οποιοδήποτε σύστημα γίνεται
τόσο αργό που καλύτερα να το κάνεις reset. Έτσι για συστήματα με μνήμη
από 8GB και πάνω, βάζω 4GB swap και δεν έχω αντιμετωπίσει μέχρι
στιγμής κάποιο πρόβλημα. Φυσικά τα πράγματα αλλάζουν αν θέλουμε
suspend to disk - αλήθεια έχει πλέον κανένα νόημα αυτό με την ταχύτητα
που κάνουν boot τα σημερινά μηχανήματα;  - όπου πρέπει στη swap μας να
χωράει οποσδήποτε όλη η RAM και τυχόν swap, καθώς και για servers όπου
κάποιος μπορεί να θέλει περισσότερη swap.

---
Konstantinos Togias
M.Sc. in Mathematics of Computers and Decision Making
Software & Web Applications Developer


2015-07-28 10:56 GMT+03:00 pc_magas <pc_magas at openmailbox.org>:
> Πόση Ram έχεις? Ίσως να θες Παραπάνω Ram για να λύσεις το prob σου ή να
> κλείσεις ότι δεν θες η και ακόμη να τρέξεις ένα λιγότερο Μνημοβόρο UI
> πχ. LXDE, fluxbox, openbox.
>
> On 27/07/2015 11:17 μμ, Emmanouil Kapernaros wrote:
>> Όχι δεν είναι ο δίσκος, γιατί τον άλλαξα και έβαλα ssd με φρέσκια
>> εγκατάσταση και γίνεται πάλι το ίδιο ακριβώς, με τη διαφορά ότι επειδή ο
>> ssd είναι πιο γρήγορος έχω 5 δευτερόλεπτα να το σώσω με killall της
>> εφαρμογής που το προκάλεσε. Πριν με τον hdd απλά έκλεινα το laptop.
>>
>> Παρόλαυτά έτρεξα το προγραμματάκι και εδώ είναι τα αποτελέσματα:
>> http://pastebin.com/dCeQRCQH
>>
>>  <http://mkapernaros@di.uoa.gr>
>>
>> Emmanouil Kapernaros / MSc Student
>> manolis at kapcom.gr / +30 697 38 49 860
>>
>> National and Kapodistrian University of Athens
>>   Department of Informatics and Telecommunications INFORMATION TECHNOLOGIES
>> IN MEDICINE AND BIOLOGY
>>
>> [image: Twitter] <https://twitter.com/kapcom01> [image: LinkedIn]
>> <http://gr.linkedin.com/in/emmanouilkapernaros> [image: Github]
>> <https://github.com/kapcom01> [image: Stack Overflow]
>> <http://stackoverflow.com/users/2473328/kapcom01>
>>
>> Στις 27 Ιουλίου 2015 - 10:48 μ.μ., ο χρήστης NikTh <nikth at linuxmail.org>
>> έγραψε:
>>
>>> Έτσι όπως περιγράφεις το πρόβλημα, μάλλον για πρόβλημα δίσκου (hardware)
>>> φαίνεται περισσότερο.
>>>
>>> Δες εδώ[1] και αφού ακολουθήσεις τα βήματα, κάνε επικόλληση όλα τα
>>> αποτελέσματα.
>>>
>>> [1]: https://forum.ubuntu-gr.org/viewtopic.php?f=9&t=19749#p202359
>>>
>>> On 07/27/2015 10:20 PM, Emmanouil Kapernaros wrote:
>>>> Καλησπέρα,
>>>>
>>>> Έχω ένα πρόβλημα τουλάχιστον στις 3 τελευταίες εκδόσεις τους Ubuntu. Τώρα
>>>> έχω το 15.04.
>>>>
>>>> Ο υπολογιστής ξαφνικά πιάνει 100% CPU και HDD χωρίς προφανή λόγο. Συνήθως
>>>> γίνεται όταν είναι ανοιχτός ο firefox και ταυτόχρονα ανοίξω και τον
>>>> chromium. Το λαμπάκι του δίσκου μένει μόνιμα αναμμένο και όλα αρχίζουν να
>>>> πηγαίνουν αργά με αποτέλεσμα σε περίπου 5 δευτερόλεπτα να χάνω ακόμα και
>>> τη
>>>> δυνατότητα να κινώ το ποντίκι.
>>>>
>>>> Εάν πατήσω άμεσα ctr+alt+f1 και έχω προνοήσει να έχω κάνει login στο
>>>> session αυτό, τότε μπορώ να πληκτρολογήσω killall firefox και το laptop
>>>> επανέρχεται άμεσα στη φυσιολογική λειτουργία. Αν δεν έχω προνοήσει τότε
>>>> αναγκαστικά πρέπει να απενεργοποιήσω τον υπολογιστή κρατώντας το power,
>>>> μιας και σε αυτή τη κατάσταση το login καθυστερεί από αρκετά λεπτά έως
>>> για
>>>> πάντα..
>>>>
>>>> Επίσης αυτό μπορεί να συμβεί με οποιαδήποτε 2 προγράμματα ταυτόχρονα
>>>> ανοιχτά. Για παράδειγμα μπορεί να συμβεί έχωντας το spotify και το
>>> matlab,
>>>> ή το kodi και το firefox. Έχω παρατηρήσει το κόλλημα να ξεκινά ακόμα και
>>>> ανοίγοντας το dash του unity.
>>>>
>>>> Μπορείτε να μου προτείνεται ποια logs να ελέγξω; Και γενικότερα τι
>>>> ενέργειες να ακολουθήσω;
>>>>
>>>> Ευχαριστώ εκ των προταίρων,
>>>> Φιλικα,
>>>>
>>>>  <http://mkapernaros@di.uoa.gr>
>>>>
>>>> Emmanouil Kapernaros / MSc Student
>>>> manolis at kapcom.gr
>>>>
>>>> [image: Twitter] <https://twitter.com/kapcom01> [image: LinkedIn]
>>>> <http://gr.linkedin.com/in/emmanouilkapernaros> [image: Github]
>>>> <https://github.com/kapcom01> [image: Stack Overflow]
>>>> <http://stackoverflow.com/users/2473328/kapcom01>
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL: <
>>> https://lists.ubuntu.com/archives/ubuntu-gr/attachments/20150727/f43d5dbc/attachment.html
>>>>
>>> --
>>> Nick Th
>>>
>>> -------------- next part --------------
>>> A non-text attachment was scrubbed...
>>> Name: signature.asc
>>> Type: application/pgp-signature
>>> Size: 490 bytes
>>> Desc: OpenPGP digital signature
>>> URL: <
>>> https://lists.ubuntu.com/archives/ubuntu-gr/attachments/20150727/1b32a079/attachment.pgp
>>> --
>>> Ubuntu-gr mailing list
>>> Ubuntu-gr at lists.ubuntu.com
>>>
>>> If you do not want to receive any more messages from the ubuntu-gr mailing
>>> list, please follow this link and choose unsubscribe:
>>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-gr
>>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <https://lists.ubuntu.com/archives/ubuntu-gr/attachments/20150727/9fc6dd39/attachment.html>
>
>
> --
> Ubuntu-gr mailing list
> Ubuntu-gr at lists.ubuntu.com
>
> If you do not want to receive any more messages from the ubuntu-gr mailing list, please follow this link and choose unsubscribe:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-gr


More information about the Ubuntu-gr mailing list