IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PostgreSQL Discussion :

Espace disque (Vacuum : 15Go => 400Mo)


Sujet :

PostgreSQL

  1. #1
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    77
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 77
    Points : 39
    Points
    39
    Par défaut Espace disque (Vacuum : 15Go => 400Mo)
    Hier, la taille de ma base de donnée était de 90Go et il ne me restait plus que 15Go.
    J'ai lancé un Vacuum standart pour libérer de la place (j'avais fait plein de delete/update).

    Le processus est encore en train de tourner, et il ne me reste plus que ... 400Mo.

    Je commence à stresser

    Que se passe-til? (je suis le seul à avoir accés à la base de donnée, et je n'y ai fait aucune modification depuis hier... sauf vacuum)

    Edit : je suis sous Postgres 8.1 et sous Windows

  2. #2
    Membre émérite
    Avatar de hpalpha
    Inscrit en
    Mars 2002
    Messages
    769
    Détails du profil
    Informations forums :
    Inscription : Mars 2002
    Messages : 769
    Points : 2 545
    Points
    2 545
    Par défaut
    Bonjour,

    quel genre de vacuum ?
    un simple vacuum ne va pas faire grand ménage, essaye de faire un VACUUM FULL sur tes tables.

    J'ai tout de meme 2 conseils :

    - change de version de pg >> 8.2 ou attend la 8.3
    - passe sous linux !!!!! la base en sera que plus rapide, et en plus tu peux utiliser le LVM pour l'espace disque c'est plus rassurant de savoir que l'on peut augmenter la taille du disque a chaud sans rien perdre)

    Sinon pour ton pb, en resumant :

    solution 1 :
    - vacuum full des tables

    Solution 2 :
    - supprime tes indexs
    - vacuum full des tables
    - creer un tablespace sur un autre disque dur
    - recree tes index avec le nouveau tablespace

    comme ca deja, tes données seront sur un disque et les index sur l'autre, ca te permettra peut etre de tenir le temps de passer sous linux ;-)


    Solution 3 :
    - backup ta base
    - installe linux avec des gros DD (ca coute plus rien)
    - restore la base
    Delphi 2009 - ZeosLib - DevExpress - TMS - PgDAC
    PostgreSQL 8.4 sous Debian
    Sites : http://postgresql.developpez.com http://dgriessinger.developpez.com

  3. #3
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    77
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 77
    Points : 39
    Points
    39
    Par défaut
    Oups, j'ai fait un lapsus :/

    Le processus qui tourne depuis hier est le VACUUM en mode FULL.
    Lorsque j'ai atteinds les 400Mo, j'ai arreter la commande et ai lancé un VACCUM normal, sans option (j'utilise pgadminIII). La taille est restée fixe depuis et tourne toujours(il fonctionne depuis 6h).

    Je me suis référé à :
    Docs Postgres8.1

    Il aurait du me liberer de la place au lieu d'en prendre

    Pour ce qui est du Linux, on attend d'avoir une bécane spécialisée pour stocker notre Base de donnée. Bécane

  4. #4
    Membre émérite
    Avatar de hpalpha
    Inscrit en
    Mars 2002
    Messages
    769
    Détails du profil
    Informations forums :
    Inscription : Mars 2002
    Messages : 769
    Points : 2 545
    Points
    2 545
    Par défaut
    Le comportement semble normal,
    en fait le vacuum prend de la place pour les fichiers temporaires, grossomodo quand tu fais du vide dans le fichier, ca ce passe comme ca :

    (un X représente un octet utile, Y un octet dont on a plus besoin )

    temps 0 (15 octects)
    fichier1: XXXYYYXXXYYXYXY

    VACUUM FULL fichier1
    temps 1
    fichier1 (15 octets): XXXYYYXXXYYXYXY
    fichier1_tmp (8octets): XXXXXXXX

    temps 2
    del fichier1
    ren fichier1_tmp fichier1

    temps 3
    fichier1 (8octets): XXXXXXXX


    C'est un peu imagé, mais ca explique pourquoi l'espace disque dispo diminue
    en temp1, des fichiers temporaires sont creer et donc prenne plus de place (on passe de 15 octects a 15+8=23 octets)

    tu me suis ?


    sinon niveau serveur, le liens chez dell marche pas, c'est quel model ?
    sinon tu as de tres bon serveurs chez la concurrence (transtec par exemple)

    Je te préconise du opteron, pg est optimisé pour ce proc, en 64bits, cela va de soit, et en SMP.
    Au niveau DD, prend du RAID 10, plus interessant que le raid 5 pour une base de données.
    RAM : mini 4 Go, mais vraiment, prend plus.
    Delphi 2009 - ZeosLib - DevExpress - TMS - PgDAC
    PostgreSQL 8.4 sous Debian
    Sites : http://postgresql.developpez.com http://dgriessinger.developpez.com

  5. #5
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    77
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 77
    Points : 39
    Points
    39
    Par défaut
    Ok, je n'ai pas osé continuer jusqu'à n'avoir plus d'espace libre du tout...
    A ton avis, je peux relancer le VACUUM FULL avec seulement les 171Mo? (je suppose qu'il effacerait les anciens fichiers temporaires lorsqu'il sera en rupture d'espace)

    J'ai corrigé le lien.
    C'est un "DELL PowerEdge™ 2900" sur lequel je compte mettre (au debut):

    • Dual Core Intel® Xeon® 5150, 2.66GHz, 4MB Cache, 1333FSB
    • 4GB FB 667MHz (2 x 2048MB dual rank)
    • 3 ou 4 DD de 300Go à 15k Tr/min


    Bien sur, pour la RAM et les DD, ce n'est qu'un début
    Je cherche à avoir un systeme me permettant de gerer quelques To de données et d'avoir un accés rapide (D'où SAS et 15k Tr/Min).
    Je vais voir ce qu'il en ai des opterons.

  6. #6
    Membre émérite
    Avatar de hpalpha
    Inscrit en
    Mars 2002
    Messages
    769
    Détails du profil
    Informations forums :
    Inscription : Mars 2002
    Messages : 769
    Points : 2 545
    Points
    2 545
    Par défaut
    145 Mo !!!! ouch c'est juste

    peut etre en stoppant ta base et en la restart, ca fera peut etre du menage.

    Pour recup de la place le temps du vacumm, supprime tes index, ca a pas l'air comme ca, mais c'est fou ce que ces petites betes prennent de la place

    Pour les stockage de plusieurs To, as tu pensé aux solutions SAN en fibre chanel, ou iSCSI ?
    Delphi 2009 - ZeosLib - DevExpress - TMS - PgDAC
    PostgreSQL 8.4 sous Debian
    Sites : http://postgresql.developpez.com http://dgriessinger.developpez.com

  7. #7
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    77
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 77
    Points : 39
    Points
    39
    Par défaut
    J'avais deja supprimé quelques index avant de lancer le VACUUM FULL...
    En supprimant les autres, ça ne va me liberer que 4Go
    Je vais essayer en nettoyant deja les petites tables.

    Disons que pour l'instant, je ne vais prendre qu'un serveur (je n'ai pour l'instant que des données de l'ordre de la centaine de giga) et je me suis donc pas interessé à ces solutions de stockage.

    Que pense tu d'un Xeon dual core?

  8. #8
    Membre émérite
    Avatar de hpalpha
    Inscrit en
    Mars 2002
    Messages
    769
    Détails du profil
    Informations forums :
    Inscription : Mars 2002
    Messages : 769
    Points : 2 545
    Points
    2 545
    Par défaut
    Les intels tiennent tres bien, mais ils ont toujours ete tres cher, c'est pour ca que je parlais d'opteron, mais ca fait longtemps que j'ai pas regardé les couts, ca a baissé je pense.

    Sinon j'ai trouvé un bench, l'intel est plutot bien
    http://tweakers.net/reviews/642/14

    Pour les disques durs, tu peux te permettre d'avoir plus de 90go et avec une tolérance de panne en plus.
    3 DD de 120go en RAID 5 minimum (soit 240 go utile)

    au prix des durs, tu peux taper dans 150 go et plus
    Delphi 2009 - ZeosLib - DevExpress - TMS - PgDAC
    PostgreSQL 8.4 sous Debian
    Sites : http://postgresql.developpez.com http://dgriessinger.developpez.com

  9. #9
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    77
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 77
    Points : 39
    Points
    39
    Par défaut
    Alors j'ai libéré la mémoire des index. Depuis ce matin, j'ai eu le même espace libre qu'hier. Mais à partir de 12h, l'espace a faibli et est tombé à 300Mo.

    Le VACUUM FULL tourne toujours! (depuis hier à 17h jusqu'à maintenant à 15h15).

    Je suis en train de voir si il y a des logs quelques part...

  10. #10
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    77
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 77
    Points : 39
    Points
    39
    Par défaut
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
     
    INFO:  vacuuming "public.option_quotes"
    INFO:  "option_quotes": found 223902959 removable, 323138941 nonremovable row versions in 5139678 pages
    DETAIL:  0 dead row versions cannot be removed yet.
    Nonremovable row versions range from 69 to 69 bytes long.
    There were 2903610 unused item pointers.
    Total free space (including removable row versions) is 16535662824 bytes.
    2119290 pages are or will become empty, including 0 at the end of the table.
    2120358 pages containing 16414890024 free bytes are potential move destinations.
    CPU 110.56s/84.03u sec elapsed 5570.29 sec.
    INFO:  index "option_quotes_pkey1" now contains 323138941 row versions in 5790962 pages
    DETAIL:  104103249 index row versions were removed.
    1901289 index pages have been deleted, 20000 are currently reusable.
    CPU 197.39s/316.85u sec elapsed 14256.06 sec.
     
    ERROR:  could not extend relation 1663/25249/25758: No space left on device
    HINT:  Check free disk space.
    Et il me bloque à... 100Ko... :/
    Je suis sur que c'est un probleme de configuration, mais alors où

  11. #11
    Membre émérite
    Avatar de hpalpha
    Inscrit en
    Mars 2002
    Messages
    769
    Détails du profil
    Informations forums :
    Inscription : Mars 2002
    Messages : 769
    Points : 2 545
    Points
    2 545
    Par défaut
    tu as plus de place dispo, le vacuum te l'indique
    Delphi 2009 - ZeosLib - DevExpress - TMS - PgDAC
    PostgreSQL 8.4 sous Debian
    Sites : http://postgresql.developpez.com http://dgriessinger.developpez.com

  12. #12
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    77
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 77
    Points : 39
    Points
    39
    Par défaut
    Je le vois bien, je n'essaierais pas de faire un VACUUM FULL sinon.
    Dans toutes les docs que j'ai lu, rien n'indique que le VACUUM bouffe de la memoire, bien au contraire, il est sensé en libérer dans les cas où les DELETE/UPDATE ont été importantes (ce qui est le cas)

  13. #13
    Membre émérite
    Avatar de hpalpha
    Inscrit en
    Mars 2002
    Messages
    769
    Détails du profil
    Informations forums :
    Inscription : Mars 2002
    Messages : 769
    Points : 2 545
    Points
    2 545
    Par défaut
    Oui le vacuum libere de la memoire, mais apres qu'il ai fini de travailler.
    D'ailleurs tu peux regarder le code source,
    /src/backend/commands/vacuum.c

    il y a par exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    /*
    * Clean up working storage --- note we must do this after
    * StartTransactionCommand, else we might be trying to delete the active
    * context!
    */
    MemoryContextDelete(vac_context);
    vac_context = NULL;
    if (anl_context)
    MemoryContextDelete(anl_context);
    sinon, dans ton fichier de conf, change la valeur de maintenance_work_mem par defaut a 16Mo, passe le a plus, bcp plus, c'est le nb de ram qui sera utilisé pour le vacuum (entre autre), ca améliora la perf, et il devrait moins utiliser de DD
    Delphi 2009 - ZeosLib - DevExpress - TMS - PgDAC
    PostgreSQL 8.4 sous Debian
    Sites : http://postgresql.developpez.com http://dgriessinger.developpez.com

  14. #14
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    77
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 77
    Points : 39
    Points
    39
    Par défaut
    Bong, alors j'ai reussi à libérer 14Go sur la deuxieme table. J'ai donc relancé un VACUUM FULL sur la premiere table, et ça fait deja un peu plus de 2 jours que ça tourne... il lui reste 9Go pour finir son truc. pfff, ils auraient pu prevoir des étapes intermediaires au lieu de tout nettoyer d'un coup (ou du moins, j'espere c'est une option que je ne connais pas).

    Ouaw. J'ai pas intérêt à le faire tres souvent, c'est beaucoup trop long :/ d'autant plus que ce n'est que le début (et comme conseillé dans la doc, j'ai fais des VACUUM à des frequences regulieres avant des faire le FULL)

    J'ai mis la variable maintenance_work_mem à 256Mo. J'ai pas interet à mettre plus parceque le processus prends deja 1.5Go (limite des 2Go par processus de windaube). J'y ai vu une grande difference quand j'ai libérer de la mémoire sur la seconde table, merci!

  15. #15
    Membre expérimenté

    Inscrit en
    Mai 2002
    Messages
    720
    Détails du profil
    Informations forums :
    Inscription : Mai 2002
    Messages : 720
    Points : 1 594
    Points
    1 594
    Par défaut
    Salut

    Citation Envoyé par ledjlale
    Ouaw. J'ai pas intérêt à le faire tres souvent, c'est beaucoup trop long :/
    Tu met le doute mais j'aurai tendance à dire qu'une fois que les données sont rangées, les re-ranger doit aller relativement vite... puisqu'il n'y a rien à faire... A vérifier...

    Sous FreeBSD, une tâche cron fais un vacuum quotidien, peut être pas un hasard ?

    Smortex

    Les FAQ Assembleur - Linux
    In The Beginning Was The Command Line Neal Stephenson

  16. #16
    Membre émérite
    Avatar de hpalpha
    Inscrit en
    Mars 2002
    Messages
    769
    Détails du profil
    Informations forums :
    Inscription : Mars 2002
    Messages : 769
    Points : 2 545
    Points
    2 545
    Par défaut
    Pour le vacuum, si tes données sont plus en lecture qu'en ecriture, ta table ne devrait plus trop bouger, il faut faire une vacuum regulierement, surtout apres une serie update/insert.

    parametre l'autovacuum ca peut d'eviter des tracas.

    Sous linux, on utilisait un cron.d qui lancait un vacuum toute les nuits avant l'apparition de l'autovacuum, perso je continue a utiliser ce cron.

    Encore une fois, on voit que windows gere mal la memoire (limite de 2go), encore une bonne raison de passer sous *nux ou *bsd. (et en prime tu auras un cron et un shell puissant gratos )
    Delphi 2009 - ZeosLib - DevExpress - TMS - PgDAC
    PostgreSQL 8.4 sous Debian
    Sites : http://postgresql.developpez.com http://dgriessinger.developpez.com

  17. #17
    Membre expérimenté

    Inscrit en
    Mai 2002
    Messages
    720
    Détails du profil
    Informations forums :
    Inscription : Mai 2002
    Messages : 720
    Points : 1 594
    Points
    1 594
    Par défaut
    Citation Envoyé par hpalpha
    Encore une fois, on voit que windows gere mal la memoire (limite de 2go), encore une bonne raison de passer sous *nux ou *bsd. (et en prime tu auras un cron et un shell puissant gratos )
    Les 2Go par processus sont une limite imposée par l'architecture i386 32bits, pas de l'OS... L'OS fera juste varier comment le SWAP est utilisé puisque chaque OS à sa manière de le gérer: windows aime bien le bourrer de choses qu'il utilise, Linux l'utilise en cas de dernier recours uniquement, FreeBSD l'utilise avant que la RAM vienne a manquer et y met ce qui est alloué et non accédé depuis le plus longtemps... Selon l'usage de la mahcine chaque solution offre ses avantages et inconvénients...

    Smortex

    Les FAQ Assembleur - Linux
    In The Beginning Was The Command Line Neal Stephenson

  18. #18
    Membre émérite
    Avatar de hpalpha
    Inscrit en
    Mars 2002
    Messages
    769
    Détails du profil
    Informations forums :
    Inscription : Mars 2002
    Messages : 769
    Points : 2 545
    Points
    2 545
    Par défaut
    Citation Envoyé par hpalpha
    Encore une fois, on voit que windows gere mal la memoire (limite de 2go)
    au temps pour moi, en tout cas, je pense qu'il est deconseillé de prendre windows pour une base de données ? non ? là est un autre debat...
    Delphi 2009 - ZeosLib - DevExpress - TMS - PgDAC
    PostgreSQL 8.4 sous Debian
    Sites : http://postgresql.developpez.com http://dgriessinger.developpez.com

  19. #19
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    77
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 77
    Points : 39
    Points
    39
    Par défaut
    Oui bien sur , lorsque je vais recevoir le serveur (la semaine prochaine), j'installerais FreeBSD (surtout parceque la moitier des machines se trouvent sur cet OS). Mais en attendant, je dois me taper windows. Et si ça se trouve, les problemes que je rencontre aujourd'hui reapparaitront plus tard

    Disons que c'est tres lent parcequ'à l'origine, j'avais 200millions de lignes avant de faire un "DELETE * FROM..." (je ne connaissais pas TRUNCATE ) puis "INSERT..." * 300millions, "UPDATE INTO ...pKey_id = pKey_id+20000", puis "UPDATE INTO ... pKey_id=x WHERE pKEY_id=y"
    == Effacement de l'ancienne table, reinsertion de nouvelles données, mise à jour des ID pour synchroniser avec une autre base(brut mais facile à ecrire le programme :/
    Alors avec un peu de recul, je comprends pourquoi ça prend enormement de temps .. m'enfin, 2 jours quand meme et ce n'est même pas fini.

    Merci d'avoir corrigé à propos de l'OS, j'ai toujours vu que c'était Windows qui limitait à 2Go.

    D'apres cet article
    This 4GB space is evenly divided into two parts, with 2GB dedicated for kernel usage, and 2GB left for application usage. Each application gets its own 2GB, but all applications have to share the same 2GB kernel space.
    Mais ils parlent un peu plus bas d'un systeme qui se boot avec une option /PAE et qui permet de manipuler jusqu'à 64Go de mémoire physique (cet article date de 2004), mais j'ai pas tout saisi au premier coup :/

  20. #20
    Membre expérimenté

    Inscrit en
    Mai 2002
    Messages
    720
    Détails du profil
    Informations forums :
    Inscription : Mai 2002
    Messages : 720
    Points : 1 594
    Points
    1 594
    Par défaut
    Citation Envoyé par hpalpha
    au temps pour moi, en tout cas, je pense qu'il est deconseillé de prendre windows pour une base de données ? non ?
    Je dirai que ça dépends du contexte dans lequel on est... De là a aller le conseiller, comptez pas sur moi [/QUOTE]

    Citation Envoyé par hpalpha
    là est un autre debat...
    Oui, mais il est intéressant... Dans une boite où les connaissances sont limitées à Windows, où le manque d'un système de mise à jour des applications n'est pas critique, où la fiabilité n'est pas critique, l'administration à distance est limitée et les coûts entrent dans la politique locale, je pense que ça peut peut être se faire... Après, il faut voir comment PostgreSQL foncitonne sous Windows (j'en sais rien): si c'est natif, c'est acceptable, si ça passe par cygwin, là on est plus proche d'une installation bidouillage pour faire des tests...

    Je me rapelle du temps où j'installais apache1 sous Windows car à l'époque je ne connaissais que ça... Le readme pendant l'installation criait en rouge "DO NOT USE ON A PRODUCTION SERVER"....

    Citation Envoyé par ledjlale
    m'enfin, 2 jours quand meme et ce n'est même pas fini.
    Pour 90 Go de données ? Ça me parrais long, c'est dans ces conditions que j'aime bien attacher un debugger sur un processus pour voir s'il est pas bloqué dans un état incertain... Ca gratte sur le disque (y'a des trucs qui se créent, changent de tailles, disparaissent) ? L'allocation mémoire du processus change ?

    Smortex

    Les FAQ Assembleur - Linux
    In The Beginning Was The Command Line Neal Stephenson

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. [Jena] [TDB] Espace disque (comme Vacuum) ?
    Par teroux dans le forum Frameworks
    Réponses: 2
    Dernier message: 31/10/2012, 11h15
  2. Espace disque....
    Par Grandad95 dans le forum Bases de données
    Réponses: 5
    Dernier message: 28/07/2004, 12h52
  3. Probleme d'espace disque (= 0)
    Par infotron dans le forum Administration système
    Réponses: 12
    Dernier message: 01/06/2004, 19h29
  4. VBScript pour obtenir l'espace disque libre
    Par Archangelo dans le forum ASP
    Réponses: 2
    Dernier message: 05/05/2004, 13h33
  5. visualiser l'espace disque occupé par ma base
    Par superdada dans le forum PostgreSQL
    Réponses: 2
    Dernier message: 08/01/2004, 15h59

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo