Problima me to pws o scheduler trexei processes me I/O requests

[Antonis Christofides]

anthony at acheloos:~$ uname -a
Linux acheloos 2.6.12 #1 SMP Tue Sep 19 10:59:51 EEST 2006 i686 GNU/Linux
anthony at acheloos:~$ nice sh -c 'while true; do true; done' &
[1] 20878
anthony at acheloos:~$ nice sh -c 'while true; do true; done' &
[2] 20882
anthony at acheloos:~$ sh -c 'while /bin/true; do true; done' &
[3] 20883
anthony at acheloos:~$ top

top - 14:18:58 up 62 days,  3:00,  3 users,  load average: 3.43, 1.22, 0.42
Tasks: 254 total,   5 running, 249 sleeping,   0 stopped,   0 zombie
 Cpu0 :  8.3% us, 25.2% sy, 66.4% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
 Cpu1 :  6.3% us, 20.9% sy, 72.8% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:   1035680k total,  1020488k used,    15192k free,    93660k buffers
Swap:  2097144k total,    90360k used,  2006784k free,   508144k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
20878 anthony   35  10  4036 1204  916 R 73.0  0.1   1:17.50 sh
20882 anthony   35  10  4036 1204  916 R 66.7  0.1   1:15.84 sh
20883 anthony   25   0  4044 1220  920 R  7.0  0.1   0:07.28 sh
 

Το πρόβλημα είναι ότι ενώ τα %1 και %2 είναι nice, καταναλώνουν έκαστο
10 φορές παραπάνω cpu time απ' ό,τι το %3, ενώ εκ πρώτης όψεως θα
έπρεπε το %3 να έχει μια απ' τις δυο cpu σχεδόν για την πάρτη του.
Βέβαια, θα μου πείτε, το 46.1% system time είναι κι αυτό δικό του κατά
το μεγαλύτερο μέρος, γιατί είναι ο χρόνος που κάνει το λειτουργικό για
το fork κλπ.  Πλην όμως αν δώσουμε σε όλα τα processes nice 0, τότε τα
%1 και %2 παίρνουν έκαστο 96% ενώ το %3 μαζί με το system time είναι
8%.

Αυτά συμβαίνουν στο πείραμα.  Στην πράξη, τα %1 και %2 είναι παιδιά
του apache (με nice 0), που για κάποιο λόγο κάνουν endless loop, ενώ
το %3 είναι ο slapd, που στην ουσία δεν αποκρίνεται καθόλου με
αποτέλεσμα να κολλάνε όλοι οι clients, μέχρι ο διαχειριστής να
σκοτώσει τα κολλημένα παιδιά.  Το πρόβλημα δηλαδή δεν έχει σχέση με το
nice, απλά προσέθεσα το nice για να δείξω πόσο παρανοϊκό είναι το θέμα
(ένας συνάδελφος είχε βάλει κάτι υπολογισμούς να γίνονται με nice,
χωρίς να φαντάζεται ότι θα κολλούσε όλο το σύστημα).

Πάμε τώρα να το αναλύσουμε λίγο.  Το true είναι shell built-in· έτσι,
τα processes %1 και %2 δεν κάνουν κανένα I/O request· είναι αυτό που
στα ελληνικά θα λέγαμε "computationally intensive", και κάθε φορά
τρέχουν ώσπου το time slice τους να εξαντληθεί.  Το process %3,
ωστόσο, τρέχει το /bin/true, που σημαίνει ότι ξεσκίζεται στα fork και
λοιπά blocking I/O requests.  Πληροφορούμαι ότι το nice συνήθως δεν
επηρεάζει το μέγεθος του time slice, αλλά μόνο το πόσο ψηλά μπαίνει το
process στην ουρά για εκτέλεση.  Οπότε το σύστημα λειτουργεί κάπως
έτσι:

  1. Το %3 εκτελείται, και πολύ σύντομα, πολύ πριν εξαντλήσει το time
     slice του, κάνει ένα I/O request.
  2. O scheduler βάζει το %3 για ύπνο, και βάζει για τρέξιμο ένα άλλο
     runnable process, που στην περίπτωσή μας είναι το %1 ή το %2, που
     εξαντλεί το time slice του εφόσον δεν κάνει κανένα I/O request.
  3. Πάλι στο 1.

Και τώρα οι απορίες μου:

  1. Τι πρέπει να κάνω για να μη σέρνεται ο slapd κάθε φορά που
     κολλάνε δυο άσχετα processes; (όταν λέμε σέρνεται εννοούμε ότι
     αντί να απαντήσει σε 0.1 δευτερόλεπτα απαντάει σε πάνω από 1
     λεπτό - η κατάσταση είναι πολύ χειρότερη απ' ό,τι στο άνω
     πείραμα, που οφείλεται, πιθανολογώ, στο ότι ο slapd κάνει πολύ
     περισσότερα I/O requests).
  2. Γιατί όταν κολλάνε δύο άσχετα processes, μόνο ο slapd αρχίζει να
     σέρνεται;  Γιατί, π.χ., τα queries μου προς την postgresql
     εξακολουθούν να λειτουργούν με λογική καθυστέρηση; Δεν κάνουν και
     τα RDBMS, όπως και ο slapd, πολλά blocking I/O requests;