1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
<?xml version="1.0" encoding="utf-8"?>
<chapter>
<title>Χρησιμοποιήστε το <application>Massif</application> για το προφίλ της χρήσης της μνήμης σε εφαρμογές του GNOME</title>
<para>Αυτό το άρθρο περιγράφει πώς χρησιμοποιείται ο δημιουργός προφίλ <application>Massif</application> με εφαρμογές του GNOME. Περιγράφουμε πώς να το καλέσετε, να το ερμηνεύσετε και πώς να ενεργήσετε βάσει των αποτελεσμάτων του. Ως παράδειγμα χρησιμοποιούμε το παιχνίδι <application>Ίδια GNOME</application>.</para>
<sect1 id="optimization-massif-TBL-intro">
<title>Εισαγωγή</title>
<para>Το <application>Massif</application> είναι μέλος της σουίτας εργαλείων δημιουργίας προφίλ χρήσης μνήμης <ulink type="http" url="http://valgrind.org/">valgrind</ulink>. Ο σκοπός του είναι να δίνει μια λεπτομερή προβολή της δυναμικής χρήσης της μνήμης κατά τη διάρκεια εκτέλεσης ενός προγράμματος. Συγκεκριμένα, καταγράφει τη χρήση της μνήμης από το δένδρο heap και τη στοίβα.</para>
<para>Η heap είναι η περιοχή στη μνήμη η οποία κατανέμεται με συναρτήσεις όπως η malloc. Μεγαλώνει κατά απαίτηση και είναι συνήθως η μεγαλύτερη περιοχή της μνήμης σε ένα πρόγραμμα. Η στοίβα είναι εκεί όπου αποθηκεύονται όλα τα τοπικά δεδομένα για τις συναρτήσεις. Αυτό συμπεριλαμβάνει τις «αυτόματες» μεταβλητές στη C και τη διεύθυνση επιστροφής για τις υπορουτίνες. Η στοίβα είναι τυπικά πολύ μικρότερη και πολύ πιο ενεργή από τη heap. Δε θα ασχοληθούμε ειδικά με τη στοίβα μια που το <application>Massif</application> την αντιμετωπίζει σαν να ήταν μέρος της heap. Το <application>Massif</application> παρέχει επίσης πληροφορίες για την ποσότητα της μνήμης που χρησιμοποιείται για τη διαχείριση της heap.</para>
<para>Το <application>Massif</application> παράγει δύο αρχεία εξόδου: μια γραφική επισκόπηση σε ένα αρχείο postscript και μια λεπτομερή ανάλυση σε ένα αρχείο κειμένου.</para>
</sect1>
<sect1 id="optimization-massif-TBL-using-massif">
<title>Χρήση του <application>Massif</application> με το GNOME</title>
<para>Το <application>Massif</application> έχει πολύ λίγες επιλογές και για τα περισσότερα προγράμματα δεν τις χρειάζεστε. Εντούτοις για της εφαρμογές του GNOME, όπου η κατανομή μνήμης μπορεί να θαφτεί βαθιά στο glib ή στο GTK, ο αριθμός επιπέδων κάτω από την κλήση-σωρού που το Massif κατεβαίνει θα πρέπει να αυξηθεί. Αυτό είναι γίνεται χρησιμοποιώντας την παράμετρο --depth. Εξ ορισμού αυτό είναι ίσο με 3; αυξάνοντας το σε 5 εγγυάται ότι η κλήση-σωρού θα φθάσει στον κώδικά σας. Ένα ή δύο περισσότερα επίπεδα μπορούν επίσης να είναι επιθυμητά και να παρέχουν στον κώδικά σας κάποιο πλαίσιο εφαρμογής. Δεδομένου ότι το επίπεδο λεπτομέρειας γίνεται γρήγορα συντριπτικό είναι καλύτερο να αρχίσει με μικρότερη παράμετρο βάθους και να το αυξήστε μόνο όταν γίνεται προφανές ότι αυτό δεν είναι ικανοποιητικό.</para>
<para>Είναι επίσης χρήσιμο να πείτε στο <application>Massif</application> ποιες συναρτήσεις δεσμεύουν χώρο στη μνήμη μέσω του glib. Αφαιρεί ένα περιττό στρώμα κλήσεων συναρτήσεων από τις εκθέσεις και σας δίνει μια σαφέστερη ιδέα ποιος κώδικας δεσμεύει χώρο στην μνήμη. Οι συναρτήσεις δέσμευσης χώρου μνήμης μέσω του glib είναι οι g_malloc, g_malloc0, g_realloc, g_try_malloc, and g_mem_chunk_alloc. Χρησιμοποιείστε την επιλογή --alloc-fn για να ενημερώστε το Masiff για αυτές.</para>
<para>Η γραμμή-εντολών σας πρέπει επομένως να μοιάζει κάπως σαν:</para>
<programlisting>
valgrind --tool=massif --depth=5 --alloc-fn=g_malloc --alloc-fn=g_realloc --alloc-fn=g_try_malloc \
--alloc-fn=g_malloc0 --alloc-fn=g_mem_chunk_alloc same-gnome
</programlisting>
<para>Το <application>Same GNOME</application> είναι το πρόγραμμα που θα χρησιμοποιούμε σαν παράδειγμα. Σας προειδοποιούμε ότι, από την στιγμή που ο valgrind θα εξομοιώνει την ΚΜΕ, θα λειτουργεί <emphasis>πολύ</emphasis> αργά. Θα χρειαστείτε επίσης πολλή μνήμη.</para>
</sect1>
<sect1 id="optimization-massif-TBL-interpreting-results">
<title>Ερμηνεία των αποτελεσμάτων</title>
<para>Η γραφική έξοδος δεδομένων του <application>Massif</application> είναι κατά ένα μεγάλο μέρος αυτοεπεξηγηματικός. Κάθε ζώνη αντιπροσωπεύει τη μνήμη που διατίθεται από μια λειτουργία σε σχέση με τον χρόνο. Μόλις προσδιορίσετε ποιες ζώνες χρησιμοποιούν την περισσότερη μνήμη, συνήθως οι μεγάλες παχιές στην κορυφή, θα πρέπει να συμβουλευθείτε το αντίστοιχο αρχείο κειμένου για περισσότερες λεπτομέρειες.</para>
<para>Τα αρχεία κειμένων τακτοποιούνται ιεραρχικά βάση των τμημάτων, στην κορυφή είναι μία λίστα των χειρότερων χρηστών μνήμης που τακτοποιούνται κατά σειρά βάση την μείωση του χωροχρόνου. Κάτω από αυτά είναι και άλλα τμήματα, κάθε ένα διαιρεί τα αποτελέσματα σε μικρότερες λεπτομέρειες καθώς προχωράτε προς την κλήση-σωρού. Για να επεξηγήσουμε αυτό θα χρησιμοποιήσουμε την έξοδος δεδομένων της εντολής παραπάνω.</para>
<figure id="optimization-massif-FIG-output-unoptimized">
<title>Έξοδος δεδομένων <application>Massif</application> για την μη-βελτιστοποιημένη έκδοση του προγράμματος <application>Same GNOME</application>.</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/massif-before.png" format="PNG"/>
</imageobject>
</mediaobject>
</figure>
<para>Το <xref linkend="optimization-massif-FIG-output-unoptimized"/> παρουσιάζει μία χαρακτηριστική έξοδος δεδομένων σε μορφή postscript από το <application>Massif</application>. Αυτό είναι το αποτέλεσμα εάν θα παίζατε μία πίστα από το παιχνίδι <application>Same GNOME</application> (έκδοση 2.8.0) και έπειτα το κλείνατε. Το αρχείο postscript θα έχει ένα όνομα όπως <filename>massif.12345.ps</filename> και το αρχείο κειμένων θα ονομάζεται <filename>massif.12345.txt</filename>. Ο αριθμός στη μέση είναι η ταυτότητα διαδικασίας του προγράμματος που εξετάστηκε. Εάν δοκιμάσετε πραγματικά αυτό το παράδειγμα θα βρείτε δύο εκδόσεις κάθε αρχείου, με ελαφρά διαφορετικούς νούμερα, αυτό συμβαίνει γιατί το <application>Same GNOME</application> κάνει έναρξη μια δεύτερη διαδικασία και το <application>Massif</application> ακολουθεί και αυτή επίσης. Θα αγνοήσουμε αυτήν την δεύτερη διαδικασία, μια που καταναλώνει πολύ λίγη μνήμη.</para>
<para>Στην κορυφή της γραφικής παράστασης βλέπουμε μια μεγάλη κίτρινη ζώνη με τίτλο gdk_pixbuf_new. Αυτό φαίνεται ως ένας ιδανικός υποψήφιος για βελτιστοποίηση, αλλά θα πρέπει να χρησιμοποιήσουμε το αρχείο κειμένων για να ανακαλύψουμε τι καλεί το gdk_pixbuf_new. Στην κορυφή του αρχείου κειμένων θα εμφανίζεται κάτι σαν το επόμενο:</para>
<programlisting>
Εντολή: ./same-gnome
== 0 ===========================
Συναρτήσεις κατανομής σωρών που καταμετρήθηκε ως το 90.4% από το μετρίσιμο χωρόχρoνο
Καλείται από:
28.8% : 0x6BF83A: gdk_pixbuf_new (στο /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
6.1% : 0x5A32A5: g_strdup (στο /usr/lib/libglib-2.0.so.0.400.6)
5.9% : 0x510B3C: (μέσα στο /usr/lib/libfreetype.so.6.3.7)
3.5% : 0x2A4A6B: __gconv_open (στο /lib/tls/libc-2.3.3.so)
</programlisting>
<para>Η γραμμή με το σύμβολο του '=' δείχνει πόσο βαθιά κάτω είμαστε στο ίχνος σωρού, σε αυτήν την περίπτωση είμαστε στην κορυφή. Μετά από αυτό απαριθμεί τους βαρύτερους χρήστες της μνήμης έτσι ώστε να μειωθεί ο χωρόχρονος. Ο χωρόχρονος είναι το λόγος του ποσού της μνήμης που χρησιμοποιείται και του χρόνου χρησιμοποίησης του. Αντιστοιχεί στον περιοχή των ζωνών στη γραφική παράσταση. Αυτό το μέρος του αρχείου μας λέει αυτό που ξέρουμε ήδη: το μεγαλύτερο μέρος του χωροχρόνου αφιερώνεται στο gdk_pixbuf_new. Για να ανακαλύψουν τι κάλεσε το gdk_pixbuf_new πρέπει να ψάξουμε περαιτέρω μέσα στο αρχείο κειμένου:</para>
<programlisting>
== 4 ===========================
Πλαίσιο καταμέτρησης για το 28.8% του υπολογίσιμου χωροχρόνου
0x6BF83A: gdk_pixbuf_new (στο /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
0x3A998998: (μέσα στο /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so)
0x6C2760: (μέσα στο /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
0x6C285E: gdk_pixbuf_new_from_file (στο /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
Καλείται από:
27.8% : 0x804C1A3: load_scenario (same-gnome.c:463)
0.9% : 0x3E8095E: (μέσα στο /usr/lib/libgnomeui-2.so.0.792.0)
και 1 άλλη ασήμαντη θέση
</programlisting>
<para>Η πρώτη γραμμή μας λέει ότι είμαστε τώρα τέσσερα επίπεδα βαθιά μέσα στο σωρό. Από κάτω βρίσκεται η λίστα των κλήσεων λειτουργίας που μας οδηγεί από εδώ στο gdk_pixbuf_new. Τελικά υπάρχει μία λίστα λειτουργιών που είναι στο επόμενο κάτω επίπεδο και καλούν αυτές τις λειτουργίες. Υπάρχουν, φυσικά, καταχωρήσεις για τα επίπεδα 1, 2, και 3, αλλά αυτό είναι το πρώτο επίπεδο που φθάνει ακριβός στον κώδικα GDK του<application>Same GNOME</application>. Από αυτήν την λίστα, μπορούμε να δούμε αμέσως ότι ο προβλήματηκός κώδικας είναι ο load_scenario.</para>
<para>Τώρα που ξέρουμε ποιο μέρος του κώδικά μας χρησιμοποιεί όλο χωρόχρονο μπορούμε να εξετάσουμε και να ανακαλύψουμε το γιατί. Ως αποτέλεσμα βλέπουμε ότι το load_scenario φορτώνει την pixbuf από ένα αρχείο και έπειτα δεν απελευθερώνει ποτέ την μνήμη. Αφού προσδιορίσαμε τον προβληματικό κώδικα, μπορούμε να αρχίσουμε να τον διορθώνουμε.</para>
</sect1>
<sect1 id="optimization-massif-TBL-acting-on-results">
<title>Ενέργειες πάνω στα αποτελέσματα</title>
<para>Μειώνοντας την κατανάλωση του χωροχρόνου είναι κάτι καλό, αλλά υπάρχουν δύο τρόποι για την μείωση του που δεν είναι ισότιμες. Μπορείτε είτε να μειώσετε το ποσό μνήμης που διατίθεται, ή μειώστε το χρονικό διάστημα που του διατίθεται. Εξετάστε για μια στιγμή ένα πρότυπο σύστημα με μόνο δύο διαδικασίες ενεργές. Και οι δύο διαδικασίες καταναλώνουν σχεδόν όλη την φυσική μνήμη RAM και εάν κάποια στιγμή επικαλύψει η μία την άλλη το σύστημα θα κάνει αντιμετάθεση και όλα θα επιβραδύνουν. Προφανώς εάν μειώνουμε τη χρήση μνήμης σε κάθε διαδικασία με παράγοντα του δύο θα μπορούν ειρηνικά να συνυπάρξουν χωρίς την ανάγκη για αντιμετάθεση. Εάν αντ' αυτού μειώσουμε το χρόνο που διατίθεται η μνήμη με παράγοντα του δύο τότε τα δύο προγράμματα μπορούν να συνυπάρξουν, αλλά μόνο εφ' όσον οι περίοδοι υψηλής χρήσης της μνήμης τους δεν επικαλύπτονται. Έτσι είναι καλύτερο να μειωθεί το ποσό μνήμης που διατίθεται.</para>
<para>Δυστυχώς, η επιλογή της βελτιστοποίησης περιορίζεται επίσης από τις ανάγκες του προγράμματος. Το μέγεθος των δεδομένων του pixbuf στο <application>Same GNOME</application> καθορίζεται από το μέγεθος της γραφικής αναπαράστασης του παιχνιδιού και δεν μπορεί να μειωθεί εύκολα. Εντούτοις, το χρονικό διάστημα που ξοδεύει κατά την φόρτωση του στη μνήμη μπορεί να μειωθεί δραστικά. Το <xref linkend="optimization-massif-FIG-output-optimized"/> παρουσιάζει την ανάλυση του <application>Massif</application> για το <application>Same GNOME</application> μετά από την αλλαγή του για να απορρίπτει τα pixbufs μόλις φορτωθούν οι εικόνες στον διακομιστή X.</para>
<figure id="optimization-massif-FIG-output-optimized">
<title>Έξοδος δεδομένων <application>Massif</application> για την βελτιστοποιημένη έκδοση του προγράμματος <application>Same GNOME</application>.</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/massif-after.png"/>
</imageobject>
</mediaobject>
</figure>
<para>Η χρήση του χωροχρόνου από το gdk_pixbuf_new είναι τώρα μια λεπτή ζώνη που έχει σύντομες αναλαμπές (είναι τώρα η δέκατη έκτη ζώνη και βαθυπόρφυρη απόχρωση). Σαν έχτρα χαρακτηριστικό, η μέγιστη χρήση μνήμης έχει ελαττωθεί κατά 200 kB δεδομένου ότι η αιχμή εμφανίζεται πριν η μνήμη δεσμευτεί. Εάν δύο διαδικασίες όπως αυτή εκτελούνται από κοινού οι πιθανότητες της μέγιστης χρήσης μνήμης συμπίπτουν, και ως εκ τούτου ο κίνδυνος αντιμετάθεσης, θα είναι αρκετά χαμηλός.</para>
<para>Μπορούμε να το κάνουμε καλύτερα; Μια γρήγορη εξέταση της εξόδου δεδομένων του <application>Massif</application> σε κείμενο αποκαλύπτει ότι: το g_strdup είναι ο νέος σημαντικός ένοχος.</para>
<programlisting>
Εντολή: ./same-gnome
== 0 ===========================
Συναρτήσεις κατανομής σωρών που καταμετρήθηκε ως το 87.6% από το μετρίσιμο χωρόχρονο
Καλείται από:
7.7% : 0x5A32A5: g_strdup (στο /usr/lib/libglib-2.0.so.0.400.6)
7.6% : 0x43BC9F: (μέσα στο /usr/lib/libgdk-x11-2.0.so.0.400.9)
6.9% : 0x510B3C: (μέσα στο /usr/lib/libfreetype.so.6.3.7)
5.2% : 0x2A4A6B: __gconv_open (στο /lib/tls/libc-2.3.3.so)
</programlisting>
<para>Εάν το εξετάσουμε ποιο ενδελεχώς θα δούμε ότι καλείται από πολλές, πολλές, διαφορετικές θέσεις.</para>
<programlisting>
== 1 ===========================
Πλαίσιο καταμέτρησης για το 7.7% του υπολογίσιμου χωροχρόνου
0x5A32A5: g_strdup (στο /usr/lib/libglib-2.0.so.0.400.6)
Called from:
1.8% : 0x8BF606: gtk_icon_source_copy (στο /usr/lib/libgtk-x11-2.0.so.0.400.9)
1.1% : 0x67AF6B: g_param_spec_internal (στο /usr/lib/libgobject-2.0.so.0.400.6)
0.9% : 0x91FCFC: (μέσα στο /usr/lib/libgtk-x11-2.0.so.0.400.9)
0.8% : 0x57EEBF: g_quark_from_string (στο /usr/lib/libglib-2.0.so.0.400.6)
και 155 άλλες ασήμαντες θέσεις
</programlisting>
<para>Τώρα αντιμετωπίζουμε την ελάττωση της ανταμοιβή μας για τις προσπάθειες βελτιστοποίησής. Οι συμβουλές γραφικών παραστάσεων είναι μια άλλη πιθανή προσέγγιση: Και οι δύο ζώνες "other" και "heap admin" είναι αρκετά μεγάλες. Αυτό μας λέει ότι υπάρχουν πολλές μικρές κατανομές που έχουν γίνει από ποικίλες θέσεις. Η εξάλειψη τους θα είναι δύσκολη, αλλά εάν μπορέσουν να ομαδοποιηθούν τότε οι μεμονωμένες κατανομές μπορούν να γίνουν μεγαλύτερες και η επιβάρυνση του "heap admin" μπορεί να μειωθεί.</para>
</sect1>
<sect1 id="optimization-massif-TBL-caveats">
<title>Caveats</title>
<para>Υπάρχουν μερικά πράγματα που θα πρέπει να προσέξετε: Αρχικά, ο χωρόχρονος εμφανίζεται μόνο ως ποσοστό, πρέπει να το συγκρίνετε με το γενικό μέγεθος του προγράμματος για να αποφασίσει εάν το ποσό μνήμης αξίζει να δαπανηθεί. Η γραφική παράσταση, με τον κάθετο άξονα σε kilobyte, είναι ιδανικό για κάτι τέτοιο.</para>
<para>Αφετέρου,to <application>Massif</application> λαμβάνει υπόψη μόνο τη μνήμη που χρησιμοποιείται από τa προγράμματα σας. Οι πόροι όπως τα pixmaps αποθηκεύονται στον διακομιστή X και δεν εξετάζονται από το <application>Massif</application>. Στο παράδειγμα με το <application>Same GNOME</application> στην πραγματικότητα έχουμε μετακινήσει την κατανάλωση μνήμης μόνο την pixbufs από την πλευρά του προγράμματος πελάτη στα pixmaps από την πλευρά του διακομιστή. Αν και κάναμε μία μικρή απάτη, υπάρχουν κέρδη στην απόδοση. Αν κρατήσουμε τα στοιχεία εικόνας του διακομιστή X καθιστά τις ρουτίνες γραφικής αναπαράστασης γρηγορότερες και αφαιρεί πολύ διά-επεξεργαστική επικοινωνία. Επίσης, τα pixmaps θα αποθηκευτούν σε μία εγγενείς μορφή γραφικής αναπαράστασης που είναι συχνά συμπαγέστερο από το 32-μπιτη μορφή RGBA που χρησιμοποιείται από το gdk_pixbuf. Για να μετρηθεί η επίδραση των pixmaps, και άλλων πόρων του διακομιστή X χρησημοποιήστε το πρόγραμμα <ulink type="http" url="http://www.freedesktop.org/Software/xrestop">xrestop</ulink>.</para>
</sect1>
</chapter>
|
