ayant besoin d'une solution de stockage performante, je viens ici chercher
conseil.
J'ai un applicatif qui fait des stats et ecrit donc dans un fichier texte
journalier (qui change donc chaque jour) une sequence d'environ 350 octets.
Ces fichiers au fil de la journée voient donc leurs tailles augmentées.
En sachant qu'il y a environ 20000 fichiers différents et que 250 de ces
20000 fichiers sont ouverts / lus / ecrits chaque seconde (c des logs de
comptes tout betement), quelle solutions pourraient etre interessantes ?
actuellement je travaille sur ce type de config:
Bi proc Xeon 2.6
2 GO mem
dd scsi 74 go (pas de raid)
Le systeme aux heures de pointes a tendance a tomber (apres différents tests
en fait il apparait que les opé de lecture/ecriture ne se font pas assez
vite et le systeme se retrouvant avec plus de 400 proccess en simu, je vous
laisse imaginer...)
Je cherche donc une solution plus performante en matiere de stockage et je
me verrai me tourner vers ce type de config
Bi proc xeon
2 go mem
carte 3ware 9500S-8
6 * WD Raptor 74 Go (RAID 5 + 0)
Qu'en pensez vous ?
Apres lecture des docs 3ware les debits devraient etre suffisant pour
accepter le flux de lecture/ecriture - oui/non ?
L'utilisation des raptors est elle justifiées ? ils sont plus cher qu'un DD
sata classique donc bon !!
Mon probleme vient-il d'ou je pense qu'il vient ? ou est ce une mauvaise
config d'apache par ex. ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Emmanuel Florac
Le Thu, 24 Feb 2005 17:27:52 +0100, Fabrice L. a écrit :
Mon probleme vient-il d'ou je pense qu'il vient ? ou est ce une mauvaise config d'apache par ex. ?
Pour ce type de petites IO les RAID ne sont pas très performants (enfin parfois, ça dépend des cas, difficile de dire sans tester...). Par contre, il pourrait être beaucoup plus efficace d'utiliser une base de données, plutôt que des milliers de petits fichiers.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
Le Thu, 24 Feb 2005 17:27:52 +0100, Fabrice L. a écrit :
Mon probleme vient-il d'ou je pense qu'il vient ? ou est ce une mauvaise
config d'apache par ex. ?
Pour ce type de petites IO les RAID ne sont pas très performants (enfin
parfois, ça dépend des cas, difficile de dire sans tester...). Par
contre, il pourrait être beaucoup plus efficace d'utiliser une base de
données, plutôt que des milliers de petits fichiers.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
Le Thu, 24 Feb 2005 17:27:52 +0100, Fabrice L. a écrit :
Mon probleme vient-il d'ou je pense qu'il vient ? ou est ce une mauvaise config d'apache par ex. ?
Pour ce type de petites IO les RAID ne sont pas très performants (enfin parfois, ça dépend des cas, difficile de dire sans tester...). Par contre, il pourrait être beaucoup plus efficace d'utiliser une base de données, plutôt que des milliers de petits fichiers.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
Fabrice L.
Je suis mille fois d'accord !
mais je crains qu'une solution base de données ne soit vite surchargé par cette afflut d'ecriture.
une solution clusterisé avec load balancing en entrée serait l'idéal !! mais il va falloir que je cherche un mécène !!!!
Je vais tout de meme tenter l'experience en raid 5 sata avec la carte 3ware histoire de voir, l'investissement n'est pas enormissime, il sera toujours temps de passer a un systeme de BDD par la suite.
Apres meme si selon vos dires, pour les petites IO les raids ne sont pas "tres performant", si ils sont deja "performants" cela me suffira :))
merci pour votre réponse !
a+
Fab
"Emmanuel Florac" a écrit dans le message de news:
Mon probleme vient-il d'ou je pense qu'il vient ? ou est ce une mauvaise config d'apache par ex. ?
Pour ce type de petites IO les RAID ne sont pas très performants (enfin parfois, ça dépend des cas, difficile de dire sans tester...). Par contre, il pourrait être beaucoup plus efficace d'utiliser une base de données, plutôt que des milliers de petits fichiers.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
Je suis mille fois d'accord !
mais je crains qu'une solution base de données ne soit vite surchargé par
cette afflut d'ecriture.
une solution clusterisé avec load balancing en entrée serait l'idéal !! mais
il va falloir que je cherche un mécène !!!!
Je vais tout de meme tenter l'experience en raid 5 sata avec la carte 3ware
histoire de voir, l'investissement n'est pas enormissime, il sera toujours
temps de passer a un systeme de BDD par la suite.
Apres meme si selon vos dires, pour les petites IO les raids ne sont pas
"tres performant", si ils sont deja "performants" cela me suffira :))
merci pour votre réponse !
a+
Fab
"Emmanuel Florac" <eflorac@imaginet.fr> a écrit dans le message de
news:pan.2005.02.24.21.20.19.460221@imaginet.fr...
Mon probleme vient-il d'ou je pense qu'il vient ? ou est ce une mauvaise
config d'apache par ex. ?
Pour ce type de petites IO les RAID ne sont pas très performants (enfin
parfois, ça dépend des cas, difficile de dire sans tester...). Par
contre, il pourrait être beaucoup plus efficace d'utiliser une base de
données, plutôt que des milliers de petits fichiers.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
mais je crains qu'une solution base de données ne soit vite surchargé par cette afflut d'ecriture.
une solution clusterisé avec load balancing en entrée serait l'idéal !! mais il va falloir que je cherche un mécène !!!!
Je vais tout de meme tenter l'experience en raid 5 sata avec la carte 3ware histoire de voir, l'investissement n'est pas enormissime, il sera toujours temps de passer a un systeme de BDD par la suite.
Apres meme si selon vos dires, pour les petites IO les raids ne sont pas "tres performant", si ils sont deja "performants" cela me suffira :))
merci pour votre réponse !
a+
Fab
"Emmanuel Florac" a écrit dans le message de news:
Mon probleme vient-il d'ou je pense qu'il vient ? ou est ce une mauvaise config d'apache par ex. ?
Pour ce type de petites IO les RAID ne sont pas très performants (enfin parfois, ça dépend des cas, difficile de dire sans tester...). Par contre, il pourrait être beaucoup plus efficace d'utiliser une base de données, plutôt que des milliers de petits fichiers.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
Francois Petillon
On Thu, 24 Feb 2005 17:27:52 +0100, Fabrice L. wrote:
En sachant qu'il y a environ 20000 fichiers différents et que 250 de ces 20000 fichiers sont ouverts / lus / ecrits chaque seconde (c des logs de comptes tout betement), quelle solutions pourraient etre interessantes ?
Arreter d'écrire les logs dans un fichier par utilisateur et se mettre à ecrire dans de gros fichiers triés par comptes (via un process qui bufferise puis écrit) puis reprendre ces fichiers pour generer les fichiers compte par compte (cela évite d'ouvrir/fermer chaque fichier 'comptes' pour y placer une seule ligne). Avec 20K comptes, la problematique ne devrait pas être trop difficile à gerer.
François
On Thu, 24 Feb 2005 17:27:52 +0100, Fabrice L. wrote:
En sachant qu'il y a environ 20000 fichiers différents et que 250 de ces
20000 fichiers sont ouverts / lus / ecrits chaque seconde (c des logs de
comptes tout betement), quelle solutions pourraient etre interessantes ?
Arreter d'écrire les logs dans un fichier par utilisateur et se
mettre à ecrire dans de gros fichiers triés par comptes (via un process
qui bufferise puis écrit) puis reprendre ces fichiers pour generer les
fichiers compte par compte (cela évite d'ouvrir/fermer chaque fichier
'comptes' pour y placer une seule ligne). Avec 20K comptes, la
problematique ne devrait pas être trop difficile à gerer.
On Thu, 24 Feb 2005 17:27:52 +0100, Fabrice L. wrote:
En sachant qu'il y a environ 20000 fichiers différents et que 250 de ces 20000 fichiers sont ouverts / lus / ecrits chaque seconde (c des logs de comptes tout betement), quelle solutions pourraient etre interessantes ?
Arreter d'écrire les logs dans un fichier par utilisateur et se mettre à ecrire dans de gros fichiers triés par comptes (via un process qui bufferise puis écrit) puis reprendre ces fichiers pour generer les fichiers compte par compte (cela évite d'ouvrir/fermer chaque fichier 'comptes' pour y placer une seule ligne). Avec 20K comptes, la problematique ne devrait pas être trop difficile à gerer.
François
Emmanuel Florac
Le Fri, 25 Feb 2005 01:52:45 +0100, Fabrice L. a écrit :
mais je crains qu'une solution base de données ne soit vite surchargé par cette afflut d'ecriture.
Sinon quel est l'OS et le filesystem utilisé? Sur un fs comme XFS, il peut être intéressant de retarder l'écriture des logs et même de les écrire sur un device différent des données, pour accélérer un peu tout ça (et réduire énormément le nombre d'IOs).
-- Quidquid latine dictum sit, altum sonatur
Le Fri, 25 Feb 2005 01:52:45 +0100, Fabrice L. a écrit :
mais je crains qu'une solution base de données ne soit vite surchargé
par cette afflut d'ecriture.
Sinon quel est l'OS et le filesystem utilisé? Sur un fs comme XFS, il
peut être intéressant de retarder l'écriture des logs et même de les
écrire sur un device différent des données, pour accélérer un peu
tout ça (et réduire énormément le nombre d'IOs).
Le Fri, 25 Feb 2005 01:52:45 +0100, Fabrice L. a écrit :
mais je crains qu'une solution base de données ne soit vite surchargé par cette afflut d'ecriture.
Sinon quel est l'OS et le filesystem utilisé? Sur un fs comme XFS, il peut être intéressant de retarder l'écriture des logs et même de les écrire sur un device différent des données, pour accélérer un peu tout ça (et réduire énormément le nombre d'IOs).
-- Quidquid latine dictum sit, altum sonatur
Fabrice L.
plop !
le FS actuel est ext3 il me semble, sous une RH ... (honte...)
J'envisagerai bien de passer la nouvelle machine sous une debian, j'aime bien cet OS. Maintenant, a savoir quel OS est le plus adapté a mes besoins, mes compétences sont bien trop limités pour le savoir...
J'ai reflechi a passer le systeme sous une base de données, mais meme créeant une table journaliere regroupant tous les comptes utilisateurs, il y aura environ 1M de recherches dans cette table et 1M d'ecritures reparties sur une journée, tout en sachant que les 20K utilisateurs consultent leurs données chaque jour plusieurs fois soit autant de requetes supplémentaires, l'avantage des fichiers textes est que ca evite de lire un fichier global tres gros plusieurs milliers de fois par jour. Maintenant en lisant un gros fichier ou une grose BDD, peut etre que là, l'avantage du raid se ressentirait...
J'avoue etre dans une impasse et ne pas trop savoir vers quelle solution me tourner.
A votre avis ?
Fabrice
"Emmanuel Florac" a écrit dans le message de news:
mais je crains qu'une solution base de données ne soit vite surchargé par cette afflut d'ecriture.
Sinon quel est l'OS et le filesystem utilisé? Sur un fs comme XFS, il peut être intéressant de retarder l'écriture des logs et même de les écrire sur un device différent des données, pour accélérer un peu tout ça (et réduire énormément le nombre d'IOs).
-- Quidquid latine dictum sit, altum sonatur
plop !
le FS actuel est ext3 il me semble, sous une RH ... (honte...)
J'envisagerai bien de passer la nouvelle machine sous une debian, j'aime
bien cet OS.
Maintenant, a savoir quel OS est le plus adapté a mes besoins, mes
compétences sont bien trop limités pour le savoir...
J'ai reflechi a passer le systeme sous une base de données, mais meme
créeant une table journaliere regroupant tous les comptes utilisateurs, il y
aura environ 1M de recherches dans cette table et 1M d'ecritures reparties
sur une journée, tout en sachant que les 20K utilisateurs consultent leurs
données chaque jour plusieurs fois soit autant de requetes supplémentaires,
l'avantage des fichiers textes est que ca evite de lire un fichier global
tres gros plusieurs milliers de fois par jour. Maintenant en lisant un gros
fichier ou une grose BDD, peut etre que là, l'avantage du raid se
ressentirait...
J'avoue etre dans une impasse et ne pas trop savoir vers quelle solution me
tourner.
A votre avis ?
Fabrice
"Emmanuel Florac" <eflorac@imaginet.fr> a écrit dans le message de
news:pan.2005.02.25.09.42.58.403921@imaginet.fr...
mais je crains qu'une solution base de données ne soit vite surchargé
par cette afflut d'ecriture.
Sinon quel est l'OS et le filesystem utilisé? Sur un fs comme XFS, il
peut être intéressant de retarder l'écriture des logs et même de les
écrire sur un device différent des données, pour accélérer un peu
tout ça (et réduire énormément le nombre d'IOs).
le FS actuel est ext3 il me semble, sous une RH ... (honte...)
J'envisagerai bien de passer la nouvelle machine sous une debian, j'aime bien cet OS. Maintenant, a savoir quel OS est le plus adapté a mes besoins, mes compétences sont bien trop limités pour le savoir...
J'ai reflechi a passer le systeme sous une base de données, mais meme créeant une table journaliere regroupant tous les comptes utilisateurs, il y aura environ 1M de recherches dans cette table et 1M d'ecritures reparties sur une journée, tout en sachant que les 20K utilisateurs consultent leurs données chaque jour plusieurs fois soit autant de requetes supplémentaires, l'avantage des fichiers textes est que ca evite de lire un fichier global tres gros plusieurs milliers de fois par jour. Maintenant en lisant un gros fichier ou une grose BDD, peut etre que là, l'avantage du raid se ressentirait...
J'avoue etre dans une impasse et ne pas trop savoir vers quelle solution me tourner.
A votre avis ?
Fabrice
"Emmanuel Florac" a écrit dans le message de news:
mais je crains qu'une solution base de données ne soit vite surchargé par cette afflut d'ecriture.
Sinon quel est l'OS et le filesystem utilisé? Sur un fs comme XFS, il peut être intéressant de retarder l'écriture des logs et même de les écrire sur un device différent des données, pour accélérer un peu tout ça (et réduire énormément le nombre d'IOs).
-- Quidquid latine dictum sit, altum sonatur
Emmanuel Florac
Le Fri, 25 Feb 2005 14:53:31 +0100, Fabrice L. a écrit :
J'avoue etre dans une impasse et ne pas trop savoir vers quelle solution me tourner.
A votre avis ?
Déjà éviter à tout prix ext3, qui est assez piteux à tout point de vue. Commence par faire des benchmarks de ton application avec différents filesystems: reiser, xfs, jfs.
-- entia non sont multiplicanda praeter necessitatem. Guillaume d'Ockham.
Le Fri, 25 Feb 2005 14:53:31 +0100, Fabrice L. a écrit :
J'avoue etre dans une impasse et ne pas trop savoir vers quelle solution
me tourner.
A votre avis ?
Déjà éviter à tout prix ext3, qui est assez piteux à tout point de
vue. Commence par faire des benchmarks de ton application avec différents
filesystems: reiser, xfs, jfs.
--
entia non sont multiplicanda praeter necessitatem.
Guillaume d'Ockham.
Le Fri, 25 Feb 2005 14:53:31 +0100, Fabrice L. a écrit :
J'avoue etre dans une impasse et ne pas trop savoir vers quelle solution me tourner.
A votre avis ?
Déjà éviter à tout prix ext3, qui est assez piteux à tout point de vue. Commence par faire des benchmarks de ton application avec différents filesystems: reiser, xfs, jfs.
-- entia non sont multiplicanda praeter necessitatem. Guillaume d'Ockham.
