Harvard Business School of Echec - memory

Le gestionnaire de paquets de Mandriva Spring

Benoît Dejean — Mon, 05 May 2008 10:23:00 +0200

A l'invitation de liberf0rce, je me lance dans un test limité de Mandriva. J'installe et je regarde le gestionnaire de paquets. En vrac.

J'ai donc téléchargé le DVD de la 2008.1 version libre. Ca s'installe sans problème, je choisis GNOME et ça roule. Pas de LVM par défaut et je n'ai pas vu de SELinux. L'installation est rapide. Les actes d'administration se font en rentrant le mot de passe root.
J'arrive en terrain connu sur mon bureau GNOME: les menus sont bien remplis (et pas bourrés) avec des applications que je ne connaissais même pas telles que Homebank. Je repère tout de suite le Centre de Contrôle, c'est là que je vais sévir. Je remarque aussi une applet réseau, qui ressemble un peu à NetworkManager.

RPMdrake

Le gestionnaire de paquets de Mandriva s'appelle RPMdrake et se lance depuis le Centre de Contrôle. On peut visualiser les programmes avec des filtres : applications graphiques, métapaquets et listes de RPM. C'est pas mal mais je suis un peu déçu parce que tous les noms/descriptions de paquets ne sont pas en français alors que les catégories le sont.

Autodestruction

J'ai d'abord essayé de supprimer nautilus. J'ai été averti que task-gnome-minimal allez être supprimé. J'ai donc annulé pour continuer un peu.

Alexandria

Je fouille un peu pour installer alexandria. Mais lequel ?

Métapaquets

Je décide d'installer de quoi coder: je trouve un métapaquet de développement en C++. Je le sélectionne, je fais appliquer, et l'inquisition commence:

est-ce que je veux libc-dev ou ulibc-dev ?
libstdcppxyz ou libstdcppabc ?
etc

Ce n'est pas un problème spécifique aux métapaquets, ça le fait partout si plusieurs paquets peuvent résoudre les dépendances. Ce n'est pas compréhensible du tout et je me demande bien ce qui peut arriver si on fait des choix malheureux qui entrent en conflits avec des paquets déjà installés.

Au final ça s'installe et ça prend énormément de temps. Ca à l'air de fonctionner comme ceci: télécharger un paquet, l'installer, passer au suivant. Les barres de progression sont multiples: quand un paquet s'installe, on voit la barre du paquet, quand ça télécharge, on voit celle du téléchargement, et des fois quand on a de la chance, on voit la barre de progression globale. C'est dommage, la barre de progression globale "X paquets installés sur Y" devraient toujours être visible. A chaque fois que je voulais savoir où en était l'installation, ça m'a obligé à attendre un nouvel écran pour voir le fameux "123/217".

Glom

Je veux aussi installer Glom. Ca va être un bon test vu que glom va tirer tout un tas de dépendances, jusqu'à PostgreSQL. Après avoir répond au questionnaire, je lance par le menu et c'est l'explosion, le tackle à la gorge dans les starting blocks:

Je veux être gentil et ouvrir un bug. Je n'arrive pas à trouver dans le menu une entrée pour faire ça. Ce n'est pas non plus dans l'aide. Je retourne alors dans le Centre de Contrôle, et je trouve dans Aide:

Je mets glom, ça associe le bon paquet, feu et firefox se lance sur un bugzilla sur lequel il faut s'enregistrer. Je peux comprendre que le spam bugbuddy c'est embêtant, mais je suis un luser, j'ai pas envie de m'enregistrer pour mon bug. Tant pis. Ca me paraît problématique pour obtenir des retours des utilisateurs s'ils sont obligés de s'enregistrer.

Base de RPM verrouillée

En plein vol, j'ai reçu une notification "La base de RPM est verrouillée" et un "?" orange dans ma zone de notification. Je ne sais pas ce que ça veut dire (pas de détails) ou si je dois m'en inquiéter.

Sécurité

Je me suis promené dans le Centre de Contrôle, c'est globalement bien foutu. Mais il y a des rubriques carrément usines à gaz telle que les paramètre de sécurité.

Euh c'est quoi le "Choix par défaut" ? Et c'est plein de listes vertigineuses avec plein de options très variées, la taille de l'historique shell, les paramètres GDM, etc tout mélangé. Et surtout des tas de paramètres que je ne trouve absolument pas pertinents ni pour un luser ni pour un admin. Bref ça ne m'inspire pas vraiment confiance (puisque les choix sont cachés), ce n'est pas encore demain que je vais lâcher mon sudo vi /etc/machin

Configuration de SSH

J'ai fait ces captures d'écran et après j'ai voulu les copier sur mon ibook. Normalement, première connexion SSH == validation de clef. Mais là non, ça accepte la clef immédiatement sans question ni vérification. La configuration par défaut a un bien vilain StrictHostKeyChecking no, pas sécurisé du tout. OK une clef SSH c'est difficile à mémoriser, mais avec cette option si elle changeait, on ne le saurait même pas :/ Je m'étonne qu'OpenSSH n'est pas encore implémenté quelque chose comme :

Consommation mémoire

Ce weekend j'IRCais avec Luis à propos de la consommation mémoire des applis et je lui disais que Spring mange environ 140Meg de RAM au démarrage sans beagle. Installez un paquet et doublez !

Je me disais bien que ça ramait à fond cette installation ! Plus de 100meg pour installer des logiciels. Au final, une fois l'installation terminée, moi qui était parti de 140meg au démarrage, je me retrouve avec 140meg de swap. C'est codé en Mono ou quoi ?

ABI vs. API compatibility

Benoît Dejean — Tue, 22 Apr 2008 08:39:00 +0200

glibtop_get_proc_mem

libgtop has a function glibtop_get_proc_mem to retrieve basic memory usage of a process. It fills a struct glibtop_proc_mem which looks like:

struct _glibtop_proc_mem
{
	guint64	flags;
	guint64 size;	
	guint64 vsize;
	guint64 resident;
	guint64 share;
	guint64 rss;
	guint64 rss_rlim;
};

Yes, size/vsize and resident/rss look like duplicate. At least on the linux implementation, even if size/vsize and resident/rss come from /proc/self/stat and /proc/self/statm, you can see in linux/fs/proc/{array,task_mmu}.c that they have the same values. So, it seems to me that the only unique members of struct glibtop_proc_mem are size, resident and share (ok there are also flags which flags which members are filled and rss_lim).

linux proportional set size

Linux 2.6.25 comes with a new stat in /proc/self/smaps called pss which is even smarter/accurate than private_dirty. There's glibtop_get_proc_map which currently have all the smaps member but not this new pss. So what is the smarter way to get this new pss in libgtop without breaking everything ?

- break the ABI ?

I could simply extend struct glibtop_proc_map. That would break the ABI, which i'm allowed to because libgtop is desktop. But that's bad practice since packagers have to rebuild everything. That's a painful migration that may delay the adoption of newer versions of the library.

- break the API ?

What about cleaning up the glibtop_proc_mem duplicate members, mark unused some of them and rename rss to pss while keeping it binary compatible ? That would make the API a bit more sensible. I've scanned the Debian/unstable archive and that would break the build 3-6 packages but i would be able to submit trivial patches to fix glibtop_get_proc_mem usage. (And also add glibtop_init(); which are missing everywhere).

- hide `pss` inside `rss` ?

So what's best ?

Unix 64bits fun

Benoît Dejean — Sat, 05 Apr 2008 18:49:00 +0200

I used to work within a team of windows admins. I saw them strugling with applications requiring too much memory for Windows 32bits. Maybe some people run Windows 64bits, but i've never seen that: applications comes from everywhere and are 32bits only. Moreover, the kernel/user split is 2G/2G and that's pretty small for a Java process. Most servers i've seen have 4GB of memory (usually only 3GB are managed on common^Wbroken configs) and are dedicated to a small set of applications, so there's really no point in adding more memory. Oh, and yes, we run hundreds of Windows servers, not for fun.

But i've switched back to the bright side and left that windows world: i now play with unix servers, big filers and tape libraries. I've just realized that most of the linux workstations are 64bits and have at least 8GB of RAM. Yup, that's twice more than the biggest Windows servers we run...

This week, we had to recover a somehow low-end server and install RHEL on it. When i say 'low-end', i mean an old Dell or HP server garbage-collected to set-up some test environment, nothing valuable to the company. The server booted, and damn, the RAM-check took 40s ... 49152MB. Yes, 24 x 2GB on a 'low-end' server. So i asked my workmate why there were so much RAM on a simple server:

We don't tune applications, we add more memory. he said.

That's true unix speech

bootparam mem=128M

Benoît Dejean — Sat, 24 Nov 2007 22:21:00 +0100

Emmanuel is right. A lot of people in the world, our users, have computers with 128MiB. I can't believe it's possible to run GNOME with that few memory. At least you have to kill a couple of applets and disable all python plugins.
So on 12/8 i will boot my laptop with boot=128M for one day, to see what it feels like. If you want to follow me...

we need distributed control system

Benoît Dejean — Thu, 21 Jun 2007 09:39:00 +0200

I have a commit access to GNOME svn, so i'm able to do whatever i want with my code, and then commit it. My main free software contribution has been GNOME for a long time.
I've recently started to hack on awffull (log analyser, it's a webalizer fork, but webalizer is dead). I keep submitting patches on the mailing lists, i'm mainly interested in memory usage, which is a real issue with huge logs, and even more on 32bits (allocating more than 2GiB is risky). One of my patch provides a 7% memory usage improvement by using flexible arrays : this saves millions of malloc calls so heap admin / malloc overhead is much lower.

But, even if Steve (upstream) and the mailing list people are great and very responsive, my patches have not been merged yet. I totally understand why they are not already merged, but i have no way to provide my branch to other awffull fans. So i started stacking everything in a local git repository. But now I need again and again to resplit the patches because upstream just can't merge my changes. I now realize how much we need distributed control system (git, monotone, etc). Without it, patches get lost on mailing lists, they get obsolete, they don't apply anymore ... a big waste of work.

With a distributed control system, upstream is able to pull from contributors, merge or cherrypick.

I'm frustrated about awffull, i now better understand how people could be frustrated about GNOME.
I am sorry for everyone (hackers, packagers, etc) who work hard on free software but are unable to (easily) get their job upstream because of the stupid VCS we are still using.

bash_completion

Benoît Dejean — Fri, 20 Apr 2007 11:01:00 +0200

I am a big fan of the bash completion feature but i recently discovered it has a cost : my bash heap is 3536KiB.

This looks big because I often run more than 10 shells. So i tried -norc --noprofile and heap was then 932KiB, more decent. Just for fun, I straced bash and discovered that it was sourcing twice /etc/bash_completion and as there is nothing to prevent it from being reloaded, it really loads and process twice the same completion files. I checked my /etc/bash.rc and ~/.bashrc and they were both . /etc/bash_completion.

I've fixed my ~/.bashrc and bash heap is now 2232KiB. x10 so it actually saves up to 10MiB of memory on my system: yahoo !

memory upgrade

Benoît Dejean — Thu, 19 Apr 2007 23:11:00 +0200

Since I upgraded my ibook from 512MiB to 1.25GiB, i live in a new world. I should have upgraded earlier to put an end to my nightmare.

User memory usage is now 450MiB so the kernel/disk/buffer cache is big and makes my system faster than ever

Back when i had only 512MiB, i used to have 300MiB of swap usage :

the switch between evolution mailer and calendar used to take 15s. It's now 3s !
starting a new terminal now only takes 1s where it lasted up to 10s !
the gnome-menu is totally new to me : it's fast ! it instantly popups where it used to trash my disk for 3s before opening.
etc, etc

You can't really understand memory issues if you don't run a computer with <= 512MiB. So boot your computer with mem=256M and enjoy

evolution + bogofilter

Benoît Dejean — Sat, 17 Feb 2007 02:14:00 +0100

There is no standard bogofilter plugin for evolution. I am not happy with spamassassin/spamd/spamc CPU and RAM requirements. Like 'sa-learn --version' which takes 1.8s even on warm start...

So I wrote a tiny (stupid) ruby script to emulate SpamAssassin programs with bogofilter.

#!/usr/bin/env ruby

# 1 spam, 0 not-spam
def bogo_exec(mode)

  system 'bogofilter', '-l', mode

  exit case $?.exitstatus
    when 0
    1
    else
    0
  end
end

if ARGV.include?('--version') then
  print "SpamAssassin version 3.1.0-bogo\n"
  exit
end

if ARGV.include?('--spam') then
  bogo_exec '-s'
end

if ARGV.include?('--ham') then
  bogo_exec '-n'
end

if ARGV.include?('-c') or ARGV.include?('--exit-code') then
  bogo_exec '-u'
end

I then created symlinks {spamassassin, spamc, spamd, sa-learn} -> spam.rb in my PATH. Maybe it WAS incomplete and broken, but it NOW works. No more daemon. Mail retrieval is no longer CPU-bound. Evolution and I are happy.

Update

I have fixed the script. To feed spam/ham here is what i did :

selected a bunch of messages in evolution and Saved As '/tmp/mails'
run sa-learn --spam < /tmp/mails or sa-learn --ham < /tmp/mails