Oracle annonce un noyau Linux optimisé pour les SSD, Réactions à la publication du 24/09/2010

[Lionel]

Tout en restant cantonnés dans des marchés où le rapport capacité prix n'est pas capital, les SSD continuent doucement à gagner des parts de marché. C'est vrai dans le haut de gamme grand public mais encore plus dans le monde des serveurs où les temps d'accès très faibles et la dissipation thermique peu élevée en font des produits très intéressants.
Oracle l'a compris et a annoncé un nouveau noyau Linux fortement optimisé pour les SSD puisqu'il accélérerait de 137% les temps d'accès. Aucun détail n'a été dévoilé, mais le noyau doit probablement organiser les blocs avant leur écriture de manière à ce qu'ils soient adaptés au mieux à la structure des SSD qui diffère de celle des disques à plateau.
En plus, des systèmes de contrôle évitent que des données corrompues puissent être écrites sur les SSD.

On peut présumer qu'Apple finira aussi un jour par optimiser le noyau de Mac OS X pour tirer le meilleur parti de ce système de stockage. On apprécierait en attendant qu'ils apportent juste le support du TRIM. 
Par Lionel

[Morjice]

Clair, vivement le support du TRIM...

[NicolasO]

En l'occurence, l'annonce d'Oracle est du bluff.

Ils comparent a RHEL qui a un tres vieux noyau(pour la stabilite). Ils ont juste pris un noyau recent compile avec certaines options.

Il n'y a pas de lignes de code special pour le SSD. Les mesures sont faites sur un jeu de bench bien choisi en ignorant les autres.

C'est assez clair pour tout le monde, voir par exemple:

http://blogs.computerworld.com/16997/oracl...hes_a_new_linux

[FabriceB]

En l'occurence, l'annonce d'Oracle est du bluff.

Ils comparent a RHEL qui a un tres vieux noyau(pour la stabilite). Ils ont juste pris un noyau recent compile avec certaines options.

Il n'y a pas de lignes de code special pour le SSD. Les mesures sont faites sur un jeu de bench bien choisi en ignorant les autres.

C'est assez clair pour tout le monde, voir par exemple:

http://blogs.computerworld.com/16997/oracl...hes_a_new_linux

Il y a beaucoup plus de boulot que ça en fait. Par exemple l'integrité des données disques tel que décrite ici.

[NicolasO]

hives/6919-About-this-data-integrity-thing-in-Oracle-ULK.html#extended"]ici[/url].

Sur le website d'Oracle sur le sujet.

"Please note that as of 2.6.27 the data integrity extensions were merged into the Linux kernel. As a consequence all further development is done in the upstream kernel. This project site currently functions as a repository for design documents and presentations on DIF and DIX."

Je ne dis pas qu'Oracle ne contribue pas au noyau ou qu'il n'y a pas eu de progres entre 2.6.17 et 2.6.32, je dis juste qu'il n'y a rien de neuf dans le noyau Oracle par rapport a un autre noyau de distrib. (Toutes les distribs compilent avec les options qui conviennent pour ce qu'ils veulent faire et ajoute un ou deux patchs...)

Je suis tout a fait d'accord pour dire que linux a fait des efforts pour le SSD. Je replacais juste qu'Oracle faisait le strict minimum dans le noyau (entre 1 et 2% du code, je crois) et que cette declaration d'Oracle etait un coup de pub sans fondement.

[bilboa]

hives/6919-About-this-data-integrity-thing-in-Oracle-ULK.html#extended"]ici[/url].

Sur le website d'Oracle sur le sujet.

"Please note that as of 2.6.27 the data integrity extensions were merged into the Linux kernel. As a consequence all further development is done in the upstream kernel. This project site currently functions as a repository for design documents and presentations on DIF and DIX."

Je ne dis pas qu'Oracle ne contribue pas au noyau ou qu'il n'y a pas eu de progres entre 2.6.17 et 2.6.32, je dis juste qu'il n'y a rien de neuf dans le noyau Oracle par rapport a un autre noyau de distrib. (Toutes les distribs compilent avec les options qui conviennent pour ce qu'ils veulent faire et ajoute un ou deux patchs...)

Je suis tout a fait d'accord pour dire que linux a fait des efforts pour le SSD. Je replacais juste qu'Oracle faisait le strict minimum dans le noyau (entre 1 et 2% du code, je crois) et que cette declaration d'Oracle etait un coup de pub sans fondement.

sans compter que 2.6.27 c'est pas du recent, ca fait quelques années

[Patatrov]

Clair, vivement le support du TRIM...

C'est pas le truc qui ressemble à l'Arlésienne? Ok, je sors

[Cyril]

j'ai monté un raid 0 de 3 x ssd de 64 GB dans mon macpro 8 core 3 ghz 20 GB "early 2008" 5365

J'utilise VSL (Vienna Symphonic Library)

j'ai un setup pour chaque pupitres, pour les 3 principaux j'en ai même deux car il nécessitent plus de 16 canaux midi

Ce setup chargé en mémoire utilise 14 GB

Quand je charge ces setup (VE PRO) séparément dans VE PRO SERVER, le temps de chargement total est de 4 mn (je quite VE Pro server à la fin de chaque chargement )

Par contre si je demande a VSL de tous les charger automatiquement en mémoire(VE PRO SERVER), le temps de chargement total va de 13 à de 16 mn

En analysant le chargement avec "BigTop" et avec "activity monitor" on constate que :

- au début le taux de chargement des samples est rapide et diminue au fur et a mesure.
- il y a des période ou le chargement se repose
- Mac os utilise le swap alors qu'il lui reste plein de mémoire disponible

Conclusion MAC OS s'essouffle !!!!!!!!!

Avez vous constaté ce phénomène avec d'autres applications




Cyril

[iAPX]

Pour les performances sur les SSD, il y a auss ides filesystem adaptés aux SSD et offrant de meilleures performances que ext3/ext4... Pas ben compliqué à utiliser!
Idem pour les données de controle, tout ça n'est pas du neuf, mais juste du blabla commercial

[fabounio]

J'imagine qu'ils ont juste paramétré le scheduler en mettant "elevator=noop" ou "elevator=deadline" dans les arguments de boot du noyeau.
il y a deux trois trucs a faire sur linux comme ca pour booster les performances d'un RAID qui a du cache ou bien d'un SSD (tout support qui n'a pas vraiment de mecanique de disque dur).

en jouant aussi sur la taille de certains caches pour la lecture, ca booste enormément... sur Centos/redhat quand on a une carte RAID.
blockdev --setra 16384 /dev/diquedur/....

bon, rien de miraculeux chez oracle quoi

[aranaud]

En analysant le chargement avec "BigTop" et avec "activity monitor" on constate que :

- au début le taux de chargement des samples est rapide et diminue au fur et a mesure.
- il y a des période ou le chargement se repose
- Mac os utilise le swap alors qu'il lui reste plein de mémoire disponible

Conclusion MAC OS s'essouffle !!!!!!!!!

Avez vous constaté ce phénomène avec d'autres applications

D'après "activity monitor", le Swap n'est que de 2,3 Mb autant dire vide. Ne te fit pas à ce que dit la mémoire virtuel, elle est vraiment virtuel. Chez moi, elle monte facilement à 172 Go voir plus. Donc dans les même proposition que toi. Mais c'est impossible, il n'y a pas autant de place sur le disque dur système.

Il doit avoir d'autre problème que Mac OS X, saturation du logiciel, bande passante de la mémoire, ...

[Cyril]

En analysant le chargement avec "BigTop" et avec "activity monitor" on constate que :

- au début le taux de chargement des samples est rapide et diminue au fur et a mesure.
- il y a des période ou le chargement se repose
- Mac os utilise le swap alors qu'il lui reste plein de mémoire disponible

Conclusion MAC OS s'essouffle !!!!!!!!!

Avez vous constaté ce phénomène avec d'autres applications

D'après "activity monitor", le Swap n'est que de 2,3 Mb autant dire vide. Ne te fit pas à ce que dit la mémoire virtuel, elle est vraiment virtuel. Chez moi, elle monte facilement à 172 Go voir plus. Donc dans les même proposition que toi. Mais c'est impossible, il n'y a pas autant de place sur le disque dur système.

Il doit avoir d'autre problème que Mac OS X, saturation du logiciel, bande passante de la mémoire, ...

c'est quand même bizzzzzzzzzzzzare que Mac OS Swap alors q'il y a plein de place en mémoire, et il swap toujours vers 9 ou 10 GB d'occupé

Lundi je vais pouvoir tester avec 24 GB

On constate le même phénomène avec un disque dur de 1 to ou un SSD de 256 GO

Cyril

[FabriceB]

En analysant le chargement avec "BigTop" et avec "activity monitor" on constate que :

- au début le taux de chargement des samples est rapide et diminue au fur et a mesure.
- il y a des période ou le chargement se repose
- Mac os utilise le swap alors qu'il lui reste plein de mémoire disponible

Conclusion MAC OS s'essouffle !!!!!!!!!

Avez vous constaté ce phénomène avec d'autres applications

D'après "activity monitor", le Swap n'est que de 2,3 Mb autant dire vide. Ne te fit pas à ce que dit la mémoire virtuel, elle est vraiment virtuel. Chez moi, elle monte facilement à 172 Go voir plus. Donc dans les même proposition que toi. Mais c'est impossible, il n'y a pas autant de place sur le disque dur système.

Il doit avoir d'autre problème que Mac OS X, saturation du logiciel, bande passante de la mémoire, ...

c'est quand même bizzzzzzzzzzzzare que Mac OS Swap alors q'il y a plein de place en mémoire, et il swap toujours vers 9 ou 10 GB d'occupé

Lundi je vais pouvoir tester avec 24 GB

On constate le même phénomène avec un disque dur de 1 to ou un SSD de 256 GO

Cyril

Swapper signifie éjecter des pages vers le disques. Tous les OS sont confrontés au même dilemnes : quand il y a des vieilles pages inaccédée depuis longtemps et une activité disques importante, qui privilégier ? Le cache disque ou les pages ? C'est un problème très complexe à régler.

j'ai monté un raid 0 de 3 x ssd de 64 GB dans mon macpro 8 core 3 ghz 20 GB "early 2008" 5365

J'utilise VSL (Vienna Symphonic Library)

j'ai un setup pour chaque pupitres, pour les 3 principaux j'en ai même deux car il nécessitent plus de 16 canaux midi

Ce setup chargé en mémoire utilise 14 GB

Quand je charge ces setup (VE PRO) séparément dans VE PRO SERVER, le temps de chargement total est de 4 mn (je quite VE Pro server à la fin de chaque chargement )

Par contre si je demande a VSL de tous les charger automatiquement en mémoire(VE PRO SERVER), le temps de chargement total va de 13 à de 16 mn

En analysant le chargement avec "BigTop" et avec "activity monitor" on constate que :

- au début le taux de chargement des samples est rapide et diminue au fur et a mesure.
- il y a des période ou le chargement se repose
- Mac os utilise le swap alors qu'il lui reste plein de mémoire disponible

Conclusion MAC OS s'essouffle !!!!!!!!!

Ton appli consome 99% de temps CPU, c'est pas ça le problème plutôt ? C'est du temps system ou user ?

[aranaud]

Ton appli consome 99% de temps CPU, c'est pas ça le problème plutôt ? C'est du temps system ou user ?

D'après sa capture, c'est du user. En gros, une grosse application qui ne peut utiliser que une seul cœur. Et puis, on peut pas dire que le système Swap avec 2,3 Mo en Swap. Le problème vient de l'application.

Ce message a été modifié par aranaud - 25 Sep 2010, 16:56.

[Cyril]

Cette appli est bien multi cpu et on peut dire que la répartition de la charge est plutôt bonne


les 99 %, si je ne m'abuse c'est 99 % de 800 %

Théoriquement on ne swap que quand il n'y a plus de mémoire dispo

Que MAC OS Swap est une chose, mais pourquoi est-ce qu'il s'essouffle

Un autre exemple, si je charge le pupitre 1 et le 2 j'ai un temps différent que si je charge le pupitre 2 puis le 1

C'est vraiment bizzzzzzzzzzzzzzzzare

Cyril

[aranaud]

Cette appli est bien multi cpu et on peut dire que la répartition de la charge est plutôt bonne

les 99 %, si je ne m'abuse c'est 99 % de 800 %

Nan, voir capture. J'avais pas sous la main de quoi faire dépasser une application de 100% mais tu verras que l'ensemble dépasse allègrement les 100%
[attachment=35439:Capture_...20.00.20.png]

Pour être vraiment multi cpu, il faut dépasser les 100%. Mais pour t'en convaincre, va dans la partie Processeur de l'application Moniteur d'Activité".

Théoriquement on ne swap que quand il n'y a plus de mémoire dispo

Que MAC OS Swap est une chose, mais pourquoi est-ce qu'il s'essouffle

Un autre exemple, si je charge le pupitre 1 et le 2 j'ai un temps différent que si je charge le pupitre 2 puis le 1

C'est vraiment bizzzzzzzzzzzzzzzzare

Cyril

Je laisse le soin à quelqu'un d'autre d'expliquer comment sa fonctionne mais d'après ta capture du n'a pas de Swap remplie. Il y a toujours un fichier Swap par contre qui est créer mais qui est vide.

Ce message a été modifié par aranaud - 25 Sep 2010, 19:09.

[FabriceB]

Cette appli est bien multi cpu et on peut dire que la répartition de la charge est plutôt bonne


les 99 %, si je ne m'abuse c'est 99 % de 800 %

Si c'est des pourcentages d'une CPU, ton appli est très manifestement mono cpu. Il ne suffit pas d'avoir beaucoup de thread pour se servir efficacement de toute les CPU. Il faut aussi avoir bien organisé ses données.

Théoriquement on ne swap que quand il n'y a plus de mémoire dispo

Que MAC OS Swap est une chose, mais pourquoi est-ce qu'il s'essouffle

Il n'y a que très rarement de la mémoire vraiment disponible. Tout ce qui n'est pas utilisé par des données ou du code sera utilisé par du cache de système de fichier. L'OS peut décider d'éjecter une page de données sur disque qui n'a jamais été touchée si il constate qu'il y a de gros besoin d'IO.

Rien de bizarre, c'est pas l'OS qui a du mal mais ton appli qui ne gère pas bien des gros volumes et qui ralentis au fur et à mesure.

[Cyril]

Cette appli est bien multi cpu et on peut dire que la répartition de la charge est plutôt bonne


les 99 %, si je ne m'abuse c'est 99 % de 800 %

Si c'est des pourcentages d'une CPU, ton appli est très manifestement mono cpu. Il ne suffit pas d'avoir beaucoup de thread pour se servir efficacement de toute les CPU. Il faut aussi avoir bien organisé ses données.

Salut FabriceB

Sans vouloir te vexer, VSL est une appli multi cpu, au repos elle utilise 99 % et peut monter lors du chargement a 400 %

Plus tu lui rajoute des instruments plus elle demandera de CPU, quand je lance un symphonie assez complexe la charge CPU varie entre 50 et 60 % SUR LES 8 CPU

@+

Cyril