Devops for Growth

 

Operation Time (nsec) L1 cache reference 0.5 Branch mispredict 5 L2 cache reference 7 Mutex lock/unlock 25 Main memory reference 100 Compress 1KB bytes with Zippy 3,000 Send 2K bytes over 1 Gbps network 20,000 Read 1MB sequentially from memory 250,000 Roundtrip within same datacenter 500,000 Disk seek 10,000,000 Read 1MB sequentially from disk 20,000,000 Send packet CA -> Netherlands -> CA 150,000,000

 

Some useful figures that aren’t in Dean’s data can be found in this article comparing NetBSD 2.0 and FreeBSD 5.3 from 2005. Approximating those figures, we get:

Operation Time (nsec) System call overhead 400 Context switch between processes 3000 fork() (statically-linked binary) 70,000 fork() (dynamically-linked binary) 160,000

Le dernier numéro des Communications of the ACM [1] (CACM) contient un article intitulé Attack of the Killer Microseconds écrit par des ingénieurs de Google, dont David Patterson, qui fut dans des vies antérieures professeur à Berkeley, architecte principal des processeurs SPARC de Sun Microsystems et co-auteur avec John Hennessy (architecte principal des processeurs MIPS et actuel président de l’université Stanford) du manuel de référence sur l’architecture des ordinateurs (pour dire qu’il ne s’agit pas d’élucubrations d’amateurs).

 

(...)

Ces problèmes de temps de latence pénalisants surgissent aujourd’hui parce que des événements qui étaient relativement rares dans les traitements d’hier (appel de procédures à distance, déplacement de machine virtuelle par exemple) sont désormais au cœur des architectures de traitement de données. Tant que ces événements étaient rares, les architectes de système adoptaient des solutions simples, telles que, simplement, attendre la fin de l’action, mais dès lors que ces événements sont fréquents la pénalité encourue devient de moins en moins supportable.

Pour alléger ces pénalités, nos auteurs suggèrent de concevoir à nouveaux frais des optimisations pour les mécanismes de bas niveau, tels que contention de verrou et synchronisation. Les spécialistes du calcul à haute performance (HPC) se sont confrontés à ces problèmes depuis longtemps, mais les solutions qu’ils ont adoptées ne répondent pas forcément très bien aux questions actuelles, parce qu’ils travaillaient généralement dans un contexte où les contraintes économiques étaient faibles, ce qui n’est pas le cas des grands centres de données d’aujourd’hui.

De surcroît, les logiciels déployés par les grands opérateurs tels que Google et Amazon évoluent rapidement, ce qui impose des méthodes de génie logiciel rigoureuses et simplificatrices, impératif ignoré du monde HPC.

Des solutions doivent également être cherchées du côté des processus légers, du parallélisme à grain fin, de la gestion plus efficace des files d’attente, etc. Je ne puis mieux faire que vous recommander la lecture de cet article.