Sébastien Koechlin a écrit 849 commentaires

De ma propre expérience c'est tout à fait vrai, des ralentissements (ressenti utilisateur) dès qu'on dépasse les 150%, et vu des pics à plus de 600% sans pour autant planter la machine.

Une charge importante, même bien au dessus de 6, ne plante pas une machine. Ce qui provoque un plantage, c'est généralement d'atteindre des limites comme la mémoire virtuelle disponible ou le nombre de processus; cas souvent mal gérés; et encore, ces cas ne plantent pas souvent la machine qui se contente de faire du ménage.

Il y a quand même deux points importants à noter:

1. Une charge importante a de gros impacts sur le temps de réponse; pour un serveur qui est censé répondre dans un délais raisonnable aux requêtes reçues, ou pour un bureau de travail, ça peut tout à fait devenir inacceptable. La machine n'est pas plantée pour autant.

2. Une charge importante peut être révélatrice d'une consommation de ressources en croissance qui va aboutir à un plantage de la machine. Par exemple sur une consommation excessive de mémoire, si la machine a beaucoup de swap, elle va passer par une phase de swap intensif qui va dégrader les performances, parfois pendant un moment.

Ceci étant du aux, système de file d'attente, de nice etc... ce qui est évident, mais ce principe est t il valable sur toutes les architectures ou seulement sur x86 ?? Est ce aussi le cas sur sparc, alpha, arm, rs6000, etc ??

Le comportement est il identique avec des machines multi-processeurs (physiques) pas simplement des cœurs dans un processeur unique ??

Si tu es sur GNU/Linux, on considérer que le calcul du loadavg est le même, donc homogène. Tu as quand même le problème du nombre de cœur, un loadavg de 1.2 sur une machine bi-core n'indique pas de problème (1.2 processus a exécuter, 2 cœurs disponibles), sur un monoprocesseur c'est peut-être un problème. L'hyperthreading vient compliquer l'interprétation des valeurs.

Si tu as un parc d'OS hétérogène, alors la comparaison n'est pas réellement possible. Certains OS comptent ou ne compte pas les taches dans différents états, bloqués sur certaines ressources... Certains vont distinguer les threads et les processus, d'autres pas. Certains vont aussi normaliser la valeur par rapport au nombre de processeur, afin qu'une valeur de 1 indique toujours une occupation complète de tous les CPU, quelque soit le nombre de CPU. Bref, c'est la foire.

Il y a un article intéressant à propos d'OpenID sur http://lwn.net/Articles/425946/

Personnellement, la possibilité de se connecter via Facebook ne me gène pas trop tant qu'il y a des alternatives.

Ce que je n'aimerais pas, c'est que mon mur ou mes "amis", ou une quelconque application FB se trouve gratifiés d'informations comme "Machin sera à Lyon du 24 au 35 mai", (qui se terminerait au tribunal au premier cambriolage); ou encore que mon compte Facebook soit utilisé alors que j'ai exprès choisi une autre méthode d'authentification.

Tu définis deux virtualHost différents; ce qui te permet d'héberger deux sites différents.

En général, il y a un ou deux trucs à modifier dans la configuration pour différencier les sites (configuration de la base de donnée, racine des répertoire, url canonique...)

C'est un peu le problème de Xen, on est obligé d'utiliser un noyau antique, et vu que le dernier kernel 2.6.37 commence tout juste à intégrer le support du Dom0; il va falloir attendre un bon moment pour que la nouvelle génération arrive dans nos distributions.

L'avantage d'un système comme LVM est justement d'éviter d'avoir à copier 20 ou 30 Go de données d'un fichier ou d'une partition.

Effectivement, on peut installer directement le système de fichier sur le disque virtuel, sans partitionnement. J'en ai parlé dans mon texte. Par contre les systèmes d'installation des distributions ne le proposent pas vraiment, ça devient acrobatique.

Effectivement, en toute logique la requête est re-préparée à chaque exécution, ce qui fait perdre le gain à ne compiler qu'une seule fois la requête.

En pratique au moins deux des deux SGBD les plus populaires compensent les erreurs des développeurs et les manques d'un certain langage de web dynamique de 3 lettres commençant par P en gérant un cache des dernières requêtes exécutés, ce qui évite d'avoir à recompiler la requête à chaque fois.

tmpfs utilise la mémoire, si celle-ci vient à manquer, alors les données vont être écrites sur le swap, en commençant par les zones utilisées le moins récemment. Les vieux fichiers qui trainent depuis un moment dans /tmp ont donc toutes les chances d'être éligibles.

On lit un peu tout et n'importe quoi sur la meilleur façon d'optimiser la durée de vie des batteries. Sur l'effet mémoire ou sur d'autres effets qui existent ou qui n'existent plus selon la technologie...

Je suis bien incapable de te dire s'il vaut mieux la laisser dans ou hors du portable, déchargé, un peu chargé, très chargé. Les études sérieuses sont rares.

Je fais quand même deux remarques:

1- La chaleur entraîne souvent des dégradations au niveau chimique; il vaut mieux l'éviter à mon avis avec une batterie qui fonctionne par des réactions chimiques. Mon portable (Panasonic Toughbook vendu pour 10h30 d'autonomie) vient avec un bouton "ECO" qui permet de limiter la charge maximale de la batterie à 80%; ce qui permet de limiter la chaleur. J'ignore si ce bouton prolonge réellement la durée de vie ou si c'est un effet marketing.

2- Une batterie est toujours composée de plusieurs éléments (ou cellules) parce que les réactions d'oxydo-réduction utilisés pour produire des électrons ne permettent pas de dépasser 2 ou 3 volts ( http://sbeccompany.fr/sciences/chimie/documents/Table_potent(...) ) on est obligé d'en utiliser plusieurs en série pour atteindre le voltage des batteries actuelles.
La charge d'une cellule est une science bien maitrisée, on sait évaluer la fin de la charge au courant qu'elle accepte et à sa température. Si la charge est trop importante, on dégage beaucoup de chaleur, et on abime l'élément.
Or les fabricants de batterie et ceux d'ordinateurs (ou GSM, Téléphone, APN...) ne se posent pas trop de question: dans toutes les batteries que j'ai vu, ils collent les éléments en série et la charge se fait de façon globale sur l'ensemble. Lorsque la batterie est neuve, ça fonctionne très bien; mais le vieillissement est accéléré par cette construction. Les éléments qui s'abiment le plus vite se chargent moins, ce sont les premiers à chauffer, ce qui accélère la dégradation.
Charger les éléments indépendamment les uns des autres demanderait d'embarquer beaucoup d'électronique dans la batterie, augmenterait le prix global de l'appareil ainsi que sa durée de vie; ce qui n'est absolument pas l'objectif des fabricants. Dans l'état actuel les batteries perdent la moitié de leur capacité en un an ou deux, temps au bout du quel le matériel est prévu pour être renouvelé.

La commande magique est de regarder si STDIN est un terminal, normalement elle ne renvoie vrai que si tu es dans un terminal:

$ tty
/dev/pts/4
$ echo $?
0

$ tty < /dev/null
not a tty
$ echo $?
1


Heu, a mon avis ça ne se passe pas au même niveau.

Dans le cas que tu cites, il s'agit pour Xorg de changer de carte graphique, or la question est pour une application de changer de serveur X.

X supporte déjà l'utilisation de plusieurs cartes graphiques, il lui manque probablement la possibilité d'ajouter et de supprimer des cartes graphiques à chaud. Dans ton cas, a aucun moment, les applications ne doivent changer de serveur X, on reste sur la même machine, connecté au même processus X; c'est la couche basse qui change.

Il faut que tu lances tes applications dans un serveur VNC, tu pourras alors ensuite te connecter dessus depuis n'importe où.

A ma connaissance, les applications ne peuvent pas migrer d'un serveur X à un autre.

UDP ne garantissant pas l'ordre de réception des paquets, je n'essayerais même pas.

Pour avoir des collisions, il faut partager le média entre plusieurs interfaces; pour cela il faut avoir un hub et non pas un switch, ce qui est quand même très rare de nos jours, surtout en 100Mbps.

Non, la taille de la FAT (table d'allocation des fichiers) ne dépends pas du nombre de fichiers, elle est fixée par la taille du média. Chaque secteur du média est représenté par un certain nombre de bits.

Au bout d'un moment, on en a mis deux, mais elles ont toujours une taille fixe.

Ce qui varie avec le nombre de fichier, c'est la taille occupée par les répertoires, mais a ma connaissance c'est le cas avec tous les systèmes de fichiers.

Les secteurs de réserve utilisés pour remapper les secteurs défectueux ne sont pas numérotés ni adressables, ils ne sont donc pas comptés.

"<pubDate>Mon, 18 Aug 2008 00:00:00 -0700</pubDate>"; un peu à la ramasse ce site.

Est-ce que la machine supporte le boot via réseau (PXE) ?
Ça pourrait faire des terminaux pour un serveur LTSP.

Oui, en fait ça regroupe deux points, c'est vrai que je n'ai pas détaillé:

1. Si on publie des enregistrements SPF et qu'on envoie via le serveur du FAI, on va avoir des soucis si ceux ci ne sont pas listés. Et généralement le FAI n'indique pas quels vont être les IP sortantes. Le fait que certains FAI utilisent des IP tournantes pour contourner les RBL n'arrange rien.

Ce qui amène au second point:

2. Parfois le FAI publie un enregistrement SPF que l'on peut alors inclure dans le notre (directive include:).

N'importe quoi.

Quel est l'intérêt d'insulter et de dénigrer les gens en prenant un ton condescendant ?

Ce n'est pas n'importe quoi. Tu expliques toi même quels sont les limites de cette solution.

Un chroot n'est pas fait pour empêcher les utilisateurs d'accéder au reste du système.

http://it.slashdot.org/article.pl?sid=07/09/27/2256235

'chroot is not and never has been a security tool'

Hello,

Je ne comprends pas le problème de base.

A ma connaissance, les FAI bloquent les requêtes vers le port 25 en sortie, mais pas en entrée. Ça bloque les spameurs qui veulent attaquer les serveurs SMTP du monde entier, mais ça n'empêche pas de recevoir du mail sur ces liaisons:

Les mails arrivent bien sur le serveur sur son port 25 (avec une IP dynamique, prévoir un TTL sur l'enregistrement MX faible, de l'ordre de 5 minutes), pour les mails en sortie, il faut les envoyer vers le SMTP du FAI, c'est ce qu'on appelle un smarthost. Éventuellement adapter le SPF (si le FAI en a un).

Merci pour ces enrichissants échanges.

J'en conclus qu'il ne faut pas de compte par application.

Et pour les groupes ?

Nous arrivons à la même conclusion sur les applications qui utilisent LDAP. Je vais essayer d'être plus clair en posant des questions précises.

J'ai beau avoir lu "Les annuaires LDAP : Protocole, administration, méta-annuaires, API" et plusieurs HOWTO, et la gestion des authentifications reste floue. Et je n'ai trouvé nul part un "howto" qui explique comment un développeur doit implémenter ça dans son application.

J'ai listé les deux méthodes que j'ai rencontré, sans être capable de détailler le contenu, sans savoir quelle est la meilleur des deux. J'imagine donc les problèmes rencontrés par les développeurs qui veulent supporter LDAP.

Méthode bind:
1- Se connecter au serveur
2- Faire un bind(user, pass) pour la partie authentification
3- Et ensuite pour l'autorisation ? Lire les valeurs de l'attribut member du groupe et regarder si on est dedans ?
4- Se déconnecter

Méthode mysql:
1- Se connecter au serveur
2- Faire un bind avec l'utilisateur applicatif
3- Rechercher l'utilisateur
4- Si on l'a trouvé, lire les valeurs de l'attribut userpassword ?
5- Espérer que c'est un algo connu et vérifier en local si on obtient la même valeur ?
6- Pour les groupes, idem, lire les valeurs de l'attribut member du groupe concerné ?
7- Se déconnecter

Ces séquences sont probablement fausses, mais je ne trouve pas plus d'informations claires sur la méthode à suivre. Toute recherche sur Google de "LDAP authentification" remonte tous les cas particuliers de chaque application et tous les problèmes que les gens ont rencontré; mais pas ça.

C'est bien les referals, les opérations étendues, mais les usecase de base, dans les règles de l'art, sont difficiles à trouver.