API Meal

Les caractéristiques d'un processus

On a vu auparavant, qu'on pouvait à un moment donné avoir plusieurs processus en cours, à un temps donné. Le système doit être capable de les identifier. Pour cela il attribue à chacun d'entre eux, un numéro appelé PID (Process Identification). Un processus peut lui même créer un autre processus, il devient donc un processus parent ou père, et le nouveau processus, un processus enfant. Ce dernier est identifié par son PID, et le processus père par son numéro de processus appelé PPID (Parent Process Identification).

Tous les processus sont ainsi identifiés par leur PID, mais aussi par le PPID du processus qui la créé, car tous les processus ont été créés par un autre processus. Oui mais dans tout ça, c'est qui a créé le premier processus ? Le seul qui ne suit pas cette règle est le premier processus lancé sur le système le processus init qui n'a pas de père et qui a pour PID 1.

Visualiser les processus

On peut visualiser les processus qui tournent sur une machine avec la commande : ps (options), les options les plus intéressantes sous HP-UX sont -e (affichage de tous les processus) et -f (affichage détaillée). La commande ps -ef donne un truc du genre :

UID     PID  PPID  C STIME      TTY     TIME    COMMAND  
root    1    0     0 Dec 6      ?       1:02    init  
...  
jean    319 300    0 10:30:30   ?       0:02    /usr/dt/bin/dtsession  
olivier 321 319    0 10:30:34   ttyp1   0:02    csh  
olivier 324 321    0 10:32:12   ttyp1   0:00    ps -ef

La signification des différentes colonnes est la suivante:

• UID nom de l'utilisateur qui a lancé le process
• PID correspond au numéro du process
• PPID correspond au numéro du process parent
• C au facteur de priorité : plus la valeur est grande, plus le processus est prioritaire
• STIME correspond à l'heure de lancement du processus
• TTY correspond au nom du terminal
• TIME correspond à la durée de traitement du processus
• COMMAND correspond au nom du processus.

Pour l'exemple donné, à partir d'un shell vous avez lancé la commande ps -ef, le premier processus à pour PID 321, le deuxième 324. Vous noterez que le PPID du process " ps -ef " est 321 qui correspond au shell, par conséquent le shell est le process parent, de la commande qu'on vient de taper. Certains processus sont permanents, c'est à dire qu'ils sont lancés au démarrage du système et arrêtés uniquement à l'arrêt du système. On appelle ces process des daemons, le terme démon est une francisation, daemon sont des abréviations.

Pour voir les process d'un seul utilisateur, vous pouvez taper :

ps -u olivier

D'un UNIX à l'autre la sortie peut changer. Sous LINUX par exemple ps -Al permet une sortie assez riche, en faisant un man ps, vous aurez l'éventail de tous les paramètres possibles.

Commandes de gestion des processus

Changer la priorité d'un processus

Les processus tournent avec un certain degré de priorité, un processus plus prioritaire aura tendance à s'accaparer plus souvent les ressources du système pour arriver le plus vite possible au terme de son exécution. C'est le rôle du système d'exploitation de gérer ces priorités.

Vous disposez de la commande nice pour modifier la priorité d'un processus. La syntaxe est la suivante :

nice -valeur commande

Plus le nombre est grand, plus la priorité est faible. Par exemple une valeur de 0 donne, la priorité la plus haute 20 donne la priorité la plus faible. La fourchette de valeur dépend de l'UNIX qu'on utilise.

Par exemple :

nice -5 ps -ef

Généralement on utilise nice sur des commandes qui prennent du temps, sur des commandes courantes l'effet de nice est imperceptible. On l'utilisera par exemple pour compiler un programme.

nice -5 cc monprogramme.c

Arrêter un processus

Vous disposez de la commande kill pour arrêter un processus, on doit aussi tuer un processus. Si vous voulez arrêter un processus, vous devez connaître son PID (commande ps), puis vous tapez :

kill -9 PID

Un utilisateur ne peut arrêter que les processus qui lui appartient (qu'il a lancé). Seul l'administrateur système a le droit d'arrêter un processus ne lui appartenant pas.

Lancer en processus en tâche de fond

Pour lancer une commande quelconque, vous en saisissez le nom après le prompt du shell, tant que la commande n'est pas terminée, vous n'avez plus la main au niveau du shell, vous ne disposez plus du prompt. Si la commande prend un certain temps, votre shell ne vous donnera pas la main tant que la commande n'est pas terminée, vous êtes obligé de lancer un autre shell, pour taper une autre commande. Vous disposez d'une technique simple qui permet de lancer une commande à partir d'un shell, et de reprendre aussitôt la main. Il vous suffit de rajouter un & à la fin de commande. Celle-ci se lancera en " tâche de fond ", et vous reviendrez directement au prompt du shell.

En tapant une commande en tâche de fond, vous aurez à l'affichage :

> ps ef &  
[321]  
>

A la suite de la saisie de la commande suivie d'un &, le shell vous donne immédiatement la main, et affiche le numéro du PID du processus lancé. En lançant une commande à partir du shell sans le & à la fin, et si celle-ci prend du temps à vous rendre la main, vous pouvez faire en sorte qu'elle bascule en tâche de fond, pour que vous repreniez la main.

>netscape

Vous voulez basculer netscape en tâche de fond tapez, CTRL+Z, il va afficher

311 stopped +

311 étant le PID du process netscape. Tapez ensuite bg (pour background), vous voyez s'afficher

[311]

Ca y est votre processus netscape est en tâche de fond et le shell vous rend la main.

installer gearman sur OSX

Prérequis: libevent

S'assurer que la libevent est présente

$ ls -l /usr/local/lib/libevent*

Le cas échéant, l'installer

$ curl -L -O http://www.monkey.org/~provos/libevent-1.4.12-stable.tar.gz
$ tar -xvzf libevent-1.4.12-stable.tar.gz
$ cd libevent-1.4.12-stable
$ ./configure
$ make
$ sudo make install

Installer libgearman

$ curl -L -O http://launchpad.net/gearmand/trunk/0.9/+download/gearmand-0.9.tar.gz
$ tar -xvzf gearmand-0.9.tar.gz
$ cd gearmand-0.9
$ ./configure
$ make
$ sudo make install

Il installera aussi les 2 applications qui nous intéressent :

/usr/local/bin/gearman
/usr/local/sbin/gearmand

Assurez vous que tous les paths sont accessibles via PATH

$ echo $PATH

si /usr/local/bin ou /usr/local/sbin ne sont pas présent, les rajouter dans le path de l'utilisateur, ou mieux le path général (le fichier /etc/paths)

Commandes utiles

• lancer gearmand pour la 1re fois

  $ gearmand -vv
   INFO Starting up
   INFO Listening on :::4730 (4)
   INFO Listening on 0.0.0.0:4730 (5)
   INFO Creating wakeup pipe
   INFO Creating IO thread wakeup pipe
   INFO Adding event for listening socket (4)
   INFO Adding event for listening socket (5)
   INFO Adding event for wakeup pipe
   INFO Entering main event loop
  

• S'assurer que gearmand est entrain de tourner

  $ ps auxw | grep [g]earmand
  xavierbarbosa 21315   0.0  0,0    75664    452 s007  S+    4:57     0:00.00 gearmand -vv
  

• Vérifier que gearman écoute le port 4730 pour les jobs en TCP

  $ sudo lsof -i tcp:4730
  COMMAND    PID          USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
  gearmand 21315 xavierbarbosa    4u  IPv6 0x6e29258      0t0  TCP *:4730 (LISTEN)
  gearmand 21315 xavierbarbosa    5u  IPv4 0xa243a68      0t0  TCP *:4730 (LISTEN)
  

• Lancer gearman en mode détaché !

  $ gearmand &
  

moxi: memcached + integrated proxy + more

moxi is a memcached proxy with several features which can help keep the memcached contract whole in complicated environments. It also brings several optimizations to memcached deployments, without requiring any changes to the application software using memcached...

http://labs.northscale.com/moxi/

Memcached Functions for MySQL and Moxi: a great combination

Working at Northscale has been a lot of great fun lately! I have finally figured out how to get puppet to set up a stock Amazon instance with everything we need and have been impressed with how you can automate system setup with puppet. I remember when I worked at Grazr how much of a hassle it was for us to have to rebuild systems. Something like Puppet would have been a godsend.

Today I though I would post about how cool moxi is. If you don't know, moxi is a memcached proxy (http://labs.northscale.com/moxi/) which allows you to move any complexity of having to set up the list of memcached servers you are using. Also, moxi has some great features such as:

• De-duplication of requests for popular keys
• A front cache, L1 cache to avoid network hops
• Fire and forget SET (Like an async SET) this means "set a value, but don't wait to know if it was successful"
• Time-outs for setting the maximum time for operations

This post will show you how moxi can be used with the memcached UDFs for MySQL (https://launchpad.net/memcached-udfs). It's really quite amazingly easy. I'll even thrown in compilation of moxi and setup of moxi...

http://capttofu.livejournal.com/22534.html

FAST POLLING USING C, MEMCACHED, NGINX AND LIBEVENT

In this post I'll show you how to implement really fast polling using C and libevent, memcached and nginx. The performance of the server is over 2400 request pr. second on a not optimized Mac Book - that's 144.000 requests pr. minute.

At Plurk we use polling and we have thousands of live users hammering the service with poll requests. It's beginning to be pretty expensive so I set a goal to optimize it. We currently use this approach in production and it uses around 2% of CPU and very little memory...

http://amix.dk/blog/viewEntry/19414

$ sudo port install bzr protobuf-c pcre
$ cd src
$ bzr branch lp:libdrizzle
$ cd libdrizzle
$ ./config/autorun.sh
$ ./configure --prefix=/opt/local && make && sudo make install
$ cd ..
$ bzr branch lp:drizzle
$ cd drizzle
$ ./config/autorun.sh
$ ./configure --with-lib-prefix=/opt/local --prefix=/opt/local &&  make && sudo make install

Un bon tuto: http://pjkix.com/journal/2009/04/28/installing-drizzle-db-on-os-x/