Bonjour,
Je viens de récupérer une machine qui partait à la casse.
Elle a un Céléron 466MHz, 192mo de ram et un DD de 10go.
J'ai installé Mandriva 2006, avec 500mo de swap et tout marche bien!
J'ai peut-être la possibilité de remplacer le DD 10go par un 20go.
Est-ce que ce changement va accélérer le chargement de gros fichiers de
présentation sxi. d'Open Office? Ou faut-il mettre un DD beaucoup plus gros
(80mo) pour voir une différence?
Merci pour vos avis.
Daniel
Une autre amélioration, c'est de passer d'un disque tournant à 4200 ou 5400 tours/min vers un disque à 7200 tours, et avec un buffer plus gros. Les disques avec un buffer de 8Mo améliorent grandement les choses. Mais passer simplement de 10 à 20 Go àma ça ne change pas grand chose.
Et encore, imagine les perfs si il passe carrément au scsi! :-)
le scsi trop cher pour un particulier avec des performances qui ne seront pas visibles... le scsi etait interessant il y a 5 ans car les performances etaient flagrantes, ce n'est plus le cas le scsi est indispensable pour un serveur avec du raid et un SGBD style oracle ou SQL server ou DB2 la bases de données est vraiment le cas typique ou tous les avantages du scsi sont utilisés
On Sun, 15 Jan 2006 12:27:40 +0100, R12y
<mihamina.rakotomandimby@etu.univ-orleans.fr> wrote:
Sébastien Kirche :
Une autre amélioration, c'est de passer d'un disque tournant à 4200 ou
5400 tours/min vers un disque à 7200 tours, et avec un buffer plus gros.
Les disques avec un buffer de 8Mo améliorent grandement les choses.
Mais passer simplement de 10 à 20 Go àma ça ne change pas grand chose.
Et encore, imagine les perfs si il passe carrément au scsi! :-)
le scsi trop cher pour un particulier avec des performances qui ne
seront pas visibles...
le scsi etait interessant il y a 5 ans car les performances etaient
flagrantes, ce n'est plus le cas
le scsi est indispensable pour un serveur avec du raid et un SGBD
style oracle ou SQL server ou DB2
la bases de données est vraiment le cas typique ou tous les avantages
du scsi sont utilisés
Une autre amélioration, c'est de passer d'un disque tournant à 4200 ou 5400 tours/min vers un disque à 7200 tours, et avec un buffer plus gros. Les disques avec un buffer de 8Mo améliorent grandement les choses. Mais passer simplement de 10 à 20 Go àma ça ne change pas grand chose.
Et encore, imagine les perfs si il passe carrément au scsi! :-)
le scsi trop cher pour un particulier avec des performances qui ne seront pas visibles... le scsi etait interessant il y a 5 ans car les performances etaient flagrantes, ce n'est plus le cas le scsi est indispensable pour un serveur avec du raid et un SGBD style oracle ou SQL server ou DB2 la bases de données est vraiment le cas typique ou tous les avantages du scsi sont utilisés
l'indien
On Sun, 15 Jan 2006 19:53:01 +0100, Calimero wrote:
R12y wrote:
J'ai du mal à saisir pourquoi la notion de multi utilisateur entre en jeu dans les tests.
Il est sans doute plus question de "multiples acces aléatoires" que multi utilisateur au sens "who".
Avec un site web qui sert des dizaines de pages/fichiers par seconde, avec en plus des accès en base de données, tu te retrouves avec un disque qui croule sous de nombreuses requetes simultanées. Là dessus, les disques SCSI à 15 000tr/min gagnent sur le plan des temps d'accès (on doit etre quasiment à la moitié d'un disque à 7200tr/min). Le SCSI a aussi une gestion des files d'attentes: les requetes de la file sont réordonnées pour pouvoir servir les données avec le moins de "tours de disque" possible. Une telle technique débarque en SATA désormais (NCQ) mais il doit y avoir encore quelques optimisations à apporter et il faut des controleurs qui supportent. Et comme tu le vois dans les liens fournis par Pascal, le NCQ n'est utile que dans le cas d'accès hautement aléatoires et concurrentiels.
Petite précision: la gestion des queues de requêtes est indispensable pour implémenter des file-system journalisés fiables: il faut absolument que les écritures des informations de journalisation soient prioritaires. C'est un gros "détail" qui change tout, quand la fiabilité est désirée...
[...]
On Sun, 15 Jan 2006 19:53:01 +0100, Calimero wrote:
R12y wrote:
J'ai du mal à saisir pourquoi la notion de multi utilisateur entre en jeu
dans les tests.
Il est sans doute plus question de "multiples acces aléatoires" que
multi utilisateur au sens "who".
Avec un site web qui sert des dizaines de pages/fichiers par seconde,
avec en plus des accès en base de données, tu te retrouves avec un
disque qui croule sous de nombreuses requetes simultanées.
Là dessus, les disques SCSI à 15 000tr/min gagnent sur le plan des
temps d'accès (on doit etre quasiment à la moitié d'un disque à
7200tr/min).
Le SCSI a aussi une gestion des files d'attentes: les requetes de la
file sont réordonnées pour pouvoir servir les données avec le moins de
"tours de disque" possible. Une telle technique débarque en SATA
désormais (NCQ) mais il doit y avoir encore quelques optimisations à
apporter et il faut des controleurs qui supportent.
Et comme tu le vois dans les liens fournis par Pascal, le NCQ n'est
utile que dans le cas d'accès hautement aléatoires et concurrentiels.
Petite précision:
la gestion des queues de requêtes est indispensable pour implémenter des
file-system journalisés fiables: il faut absolument que les écritures
des informations de journalisation soient prioritaires.
C'est un gros "détail" qui change tout, quand la fiabilité est désirée...
On Sun, 15 Jan 2006 19:53:01 +0100, Calimero wrote:
R12y wrote:
J'ai du mal à saisir pourquoi la notion de multi utilisateur entre en jeu dans les tests.
Il est sans doute plus question de "multiples acces aléatoires" que multi utilisateur au sens "who".
Avec un site web qui sert des dizaines de pages/fichiers par seconde, avec en plus des accès en base de données, tu te retrouves avec un disque qui croule sous de nombreuses requetes simultanées. Là dessus, les disques SCSI à 15 000tr/min gagnent sur le plan des temps d'accès (on doit etre quasiment à la moitié d'un disque à 7200tr/min). Le SCSI a aussi une gestion des files d'attentes: les requetes de la file sont réordonnées pour pouvoir servir les données avec le moins de "tours de disque" possible. Une telle technique débarque en SATA désormais (NCQ) mais il doit y avoir encore quelques optimisations à apporter et il faut des controleurs qui supportent. Et comme tu le vois dans les liens fournis par Pascal, le NCQ n'est utile que dans le cas d'accès hautement aléatoires et concurrentiels.
Petite précision: la gestion des queues de requêtes est indispensable pour implémenter des file-system journalisés fiables: il faut absolument que les écritures des informations de journalisation soient prioritaires. C'est un gros "détail" qui change tout, quand la fiabilité est désirée...
[...]
Daniel Doumenge
Sébastien Kirche wrote:
Ce qu'il y a de bien avec Linux, c'est que comme ça exploite de façon plus efficace et plus économe le matériel , c'est capable de redonner une nouvelle jeunesse à un poste qui n'est pas capable d'exploiter un Windows XP. Quand j'avais 512 Mo de RAM, ma machine ne swappait déjà plus.
Redonner une nouvelle jeunesse à un poste, c'est mieux que la poubelle :)
Une autre amélioration, c'est de passer d'un disque tournant à 4200 ou 5400 tours/min vers un disque à 7200 tours, et avec un buffer plus gros. Les disques avec un buffer de 8Mo améliorent grandement les choses.
Mais passer simplement de 10 à 20 Go àma ça ne change pas grand chose.
C'est fait, le gain est d'environ 12% pour la plupart des applications. J'ai ensuite remplacé la barrette sdr de 64mo par une 128mo que j'avais en réserve, au total 256mo au lieu de 192mo, et là surprise! Un gain supplémentaire de 48% pour le chargement de mes gros fichiers de présentation sxi. d'Open Office :) Merci à tous de m'avoir répondu. daniel
Sébastien Kirche wrote:
Ce qu'il y a de bien avec Linux, c'est que comme ça exploite de façon
plus efficace et plus économe le matériel , c'est capable de redonner
une nouvelle jeunesse à un poste qui n'est pas capable d'exploiter un
Windows XP. Quand j'avais 512 Mo de RAM, ma machine ne swappait déjà
plus.
Redonner une nouvelle jeunesse à un poste, c'est mieux que la poubelle :)
Une autre amélioration, c'est de passer d'un disque tournant à 4200 ou
5400 tours/min vers un disque à 7200 tours, et avec un buffer plus gros.
Les disques avec un buffer de 8Mo améliorent grandement les choses.
Mais passer simplement de 10 à 20 Go àma ça ne change pas grand chose.
C'est fait, le gain est d'environ 12% pour la plupart des applications.
J'ai ensuite remplacé la barrette sdr de 64mo par une 128mo que j'avais en
réserve, au total 256mo au lieu de 192mo, et là surprise!
Un gain supplémentaire de 48% pour le chargement de mes gros fichiers de
présentation sxi. d'Open Office :)
Merci à tous de m'avoir répondu.
daniel
Ce qu'il y a de bien avec Linux, c'est que comme ça exploite de façon plus efficace et plus économe le matériel , c'est capable de redonner une nouvelle jeunesse à un poste qui n'est pas capable d'exploiter un Windows XP. Quand j'avais 512 Mo de RAM, ma machine ne swappait déjà plus.
Redonner une nouvelle jeunesse à un poste, c'est mieux que la poubelle :)
Une autre amélioration, c'est de passer d'un disque tournant à 4200 ou 5400 tours/min vers un disque à 7200 tours, et avec un buffer plus gros. Les disques avec un buffer de 8Mo améliorent grandement les choses.
Mais passer simplement de 10 à 20 Go àma ça ne change pas grand chose.
C'est fait, le gain est d'environ 12% pour la plupart des applications. J'ai ensuite remplacé la barrette sdr de 64mo par une 128mo que j'avais en réserve, au total 256mo au lieu de 192mo, et là surprise! Un gain supplémentaire de 48% pour le chargement de mes gros fichiers de présentation sxi. d'Open Office :) Merci à tous de m'avoir répondu. daniel
