Kernel swappiness και απόδοση

Θοδωρής Λύτρας aspirin at myrealbox.com
Mon Feb 19 13:28:38 EET 2007


Στις Κυριακή 18 Φεβρουάριος 2007 18:33, ο/η Giorgos Keramidas έγραψε:
> On 2007-02-17 14:20, Θοδωρής Λύτρας <aspirin at myrealbox.com> wrote:
> >Στις Παρασκευή 16 Φεβρουάριος 2007 23:21, ο/η Michael Iatrou έγραψε:
> >>When the date was Friday 16 February 2007 19:36, Θοδωρής Λύτρας wrote:
> >>> Χρησιμοποιώ το laptopάκι κατά βάση για desktop χρήση.
> >>
> >> Σε αυτή τη περίπτωση, είτε σε ενδιαφέρουν οι τεχνικές λεπτομέρειες
> >> και πρέπει να το παλέψεις περισσότερο, είτε μπορείς να το ξεχάσεις το
> >> θέμα: σε Desktop με 2GB RAM, οποιαδήποτε προσπάθεια για
> >> "βελτιστοποίηση" από τη πλευρά του swappiness είναι μάλλον γελοία.
> >
> > ΟΚ - επομένως με 2GB μου λες οτι δεν έχει σημασία το swappiness.  What
> > about 512MB? Σε desktop μηχάνημα με αυτή την ποσότητα RAM (που νομίζω
> > τόση έχει και η πλειοψηφία των φίλων συν-linux-άδων), που είναι
> > καλύτερα να βρίσκεται το swappiness?
>
> Το αν πρέπει να inactive processes να γίνονται swap out ή όχι, για να
> αφήνουν τη μνήμη σε πιο 'ενεργά processes' είναι θέμα που σε επίπεδο
> τσακωμού ξεπερνάει άνετα το γνωστό "vi vs. Emacs" flame war.
>
> Ανεξαρτήτως του μεγέθους της φυσικής μνήμης ενός μηχανήματος, το ποσοστό
> του swappiness ορίζει πόσο "επιθετικά" θα προσπαθεί ο πυρήνας να πετάξει
> σελίδες μνήμης έξω από τη φυσική μνήμη.  Ο πυρήνας προσπαθεί να το κάνει
> αυτό για να ελευθερώσει αυτή τη σελίδα φυσικής μνήμης για ένα άλλο
> πρόγραμμα (ή ακόμα και άλλο μέρος από το ίδιο πρόγραμμα), το οποίο έχει
> πιο πολύ ανάγκη από τη γρήγορη φυσική μνήμη.
>
> Αυτή η διαδικασία περιγράφεται συνήθως, στα βιβλία λειτουργικών
> συστημάτων, ως "page replacement policy" ή "page replacement algorithm".
>
> Μια περιγραφή από page replacement αλγορίθμους είναι κι εδώ:
>
>   http://en.wikipedia.org/wiki/Page_replacement_algorithm
>
> Γενικά, στο page replacement υπάρχουν δυο ακραίες καταστάσεις, μεταξύ
> των οποίων πρέπει να ισορροπήσει ο πυρήνας:
>
>   - Οι σελίδες της φυσικής μνήμης δε γίνονται ποτέ swap out.  Σε αυτή
>     την περίπτωση, η ταχύτητα και απόδοση των processes που τρέχουν
>     είναι όσο πιο καλή γίνεται, αλλά δε μπορείς να τρέξεις ταυτόχρονα
>     περισσότερα προγράμματα από αυτά που χωράνε 100% στη φυσική μνήμη.
>
>   - Οι σελίδες της φυσικής μνήμης γίνονται swap out τόσο συχνά, που οι
>     διεργασίες είναι το 100% του χρόνου τους blocked, καθώς περιμένουν
>     να βρεθεί μια σελίδα μνήμης για να γίνει page-in η σελίδα φυσικής
>     μνήμης που θέλουν να χρησιμοποιήσουν αυτή τη στιγμή.
>
> Ανάμεσα από αυτά τα δύο άκρα, που είναι (φυσικά) και τα δύο εντελώς
> υπερβολικές καταστάσεις, υπάρχουν άπειρες ενδιάμεσες καταστάσεις.  Ο
> πυρήνας του UNIX προσπαθεί -- με κάποιο τρόπο -- να βρει μια ισορροπία
> ανάμεσα σε αυτά τα δύο άκρα.  Ο τρόπος με τον οποίο προσπαθεί να βρει
> αυτή την ισορροπία αλλάζει από UNIX σε UNIX, αλλά η γενική ιδέα
> παραμένει η ίδια.
>
> Για παράδειγμα, υπάρχει ένα πολύ καλό άρθρο στο web site του
> OpenSolaris, το οποίο αναφέρεται στις ομοιότητες που έχουν σε αυτό τον
> τομέα τα λειτουργικά συστήματα Linux, Solaris και FreeBSD:
>
>  
> http://www.opensolaris.org/os/article/2005-10-14_a_comparison_of_solaris__l
>inux__and_freebsd_kernels/
>
> Είναι πολύ ενδιαφέρον το γεγονός ότι τρία UNIX, τα οποία έχουν τόσο
> διαφορετική ιστορία, τόσο μεγάλες διαφορές σε 'interface', και έχουν
> αναπτυχθεί από τόσο διαφορετικές ομάδες ανθρώπων, έχουν στην
> πραγματικότητα τόσο πολλές ομοιότητες στον τρόπο που δουλεύει το virtual
> memory subsystem του πυρήνα τους :-)
>
> Για να γυρίσουμε στο θέμα μας, όμως, οσο μεγαλύτερο swappiness
> χρησιμοποιείς, τόσο πιο "επιθετικός" θα είναι ο πυρήνας στην προσπάθειά
> του να "διώξει" σελίδες από τη φυσική μνήμη.  Κάθε page out όμως έχει
> ένα κόστος, τόσο για να "γραφτεί" η σελίδα στο backing store της (swap
> file ή swap partition) και έχει ένα πιο σημαντικό μελλοντικό κόστος,
> όταν θα χρειαστεί ένα πρόγραμμα αυτή τη σελίδα μνήμης και θα πρέπει ο
> πυρήνας να την φέρει πάλι πίσω στη φυσική μνήμη (page in).
>
> Δεν είναι εύκολο να πεις όμως ότι "σε ένα σύστημα με 512 MB φυσική μνήμη
> είναι καλό να έχεις swappiness 100%, ενώ σε ένα με 2 GB δε χρειάζεται".
> Στην πραγματικότητα, δεν είναι τόσο εύκολο να πεις ότι το swappiness
> 100% είναι ο βέλτιστος τρόπος λειτουργίας ενός οποιουδήποτε Linux, αλλά
> σίγουρα βοηθάει να έχεις καταλάβει ΠΟΛΥ ΚΑΛΑ τον τρόπο που δουλεύει το
> virtual memory subsystem του Linux.
>
> Είμαι σίγουρος ότι ο Andrew Morton ξέρει τι λέει, αλλά ακόμα κι έτσι δεν
> είμαι τόσο σίγουρος ότι μπορεί κανείς να αποφασίσει με "απλό" τρόπο αν
> το swappiness πρέπει να είναι 100% ή 50%.  Δεν έχω χρησιμοποιήσει Linux
> *τόσο* πολύ που να μπορώ να σου με σιγουριά αν το swappiness 100% θα
> δουλέψει καλά και γρήγορα με το page replacement policy που έχει ένας
> τυχαίος Linux πυρήνας.
>
> - Γιώργος

Ευχαριστώ Γιώργο, ήσουν ιδιαίτερα κατατοπιστικός. Απ'ότι καταλαβαίνω τελικά 
όλα εξαρτώνται από το κάθε επιμέρους σενάριο χρήσης.

Σκέφτομαι πάντως το εξής, και plz διόρθωσέ με αν κάνω λάθος: Οι εφαρμογές που 
χρησιμοποιώ, ακόμη και όλες μαζί αν τις ανοίξω, λίγες φορές ξεπερνούνε το 
0.5GB (στο μέλλον -λέγε με KDE4- άντε το πολύ πολύ να φτάσουν το 1GB, 
σωστά?). Επομένως άμα βάλω 2GB, το 1+ θα πάει για cache του δίσκου. Όμως αυτό 
είναι super-υπέρ-αρκετό για το δίσκο, έτσι? Δηλ. ο δίσκος θα βολευόταν άνετα 
και με 0.5GB cache. Άρα θεωρητικά θα είναι πολύ καλύτερο να κόβεις cache από 
το δίσκο, αφού ούτως ή άλλως περιττή είναι, παρά να κάνεις swap out έστω και 
την πιο "ανούσια" εφαρμογή. Και ταυτόχρονα, μπορεί κανείς να βάλει το 
overcommit_memory στο 1, ώστε οι εφαρμογές να έχουν το ελεύθερο να τρώνε όση 
μνήμη θέλουν (αφού περισσεύει), χωρίς να σκοτίζουν τον πυρήνα (και να 
ξοδεύουν cpu cycles) για να υπολογίσει πόση μνήμη πραγματικά χρειάζεται η 
κάθε εφαρμογή.

Είναι σωστό το σκεπτικό, or did I get it all wrong?

Θοδωρής

-- 
"Beauty is transitory"
"Beauty survives"
	- Mr. Spock & Capt. Kirk, "That which survives", stardate unknown
by Theodore Lytras <aspirin at myrealbox.com>




More information about the Linux-greek-users mailing list