2016-05-03 3 views
1

Pourquoi le fichier Plone data.fs est-il si volumineux, cela affectera-t-il les performances? Sur notre site actuel, le fichier dépasse 8 Go. J'ai récemment pris en charge le développement de ce projet sur une installation de Plone 3 héritée et il existe d'énormes goulots d'étranglement sur la base de données.Pourquoi le fichier Plone data.fs est-il si volumineux, cela affectera-t-il les performances?

Ma première impression est 8GB est énorme ...?

  • Aucun fichier volumineux n'est stocké.
  • Performance est probablement la base de données:
    1. Il y a un groupe de Zeo,
    2. charge équilibrée avec apache
    3. 8 core serveur vCPU avec 16 Go de RAM
    4. Toute page en cache (couche apache) est la foudre , d'autres sont incroyablement lents

MISE À JOUR

Après les suggestions ci-dessous et une enquête plus approfondie. Voici quelques statistiques du serveur:

  • Utilisation de la mémoire 15792/16045 < < --- aïe?

  • AVG CPU 300-400%, 8 processeurs, 5 x instances de zope. Je suppose que c'est très élevé? comme chaque instance utilise un seul thread CPU pour gérer une demande? C'est presque une moyenne de 100% de l'utilisation du processeur à travers les instances?

  • Disk IO est élevé au moyen 8984.85 blocs/s

Alors qu'est-ce point à? Les fichiers journaux Apache sont énormes à 7 Go ... Je vais installer logrotate. Mais sûrement ces statistiques: High disk IO ... pointent vers des problèmes de DB? L'emballage va-t-il atténuer cela? L'emballage est-il dangereux sur un site de production aussi volumineux?

+4

8 Go Data.fs est pas énorme du tout, pour une version especialy 3 Plone (qui ne utilisez plone.app.blob par défaut) mais cela dépend de beaucoup d'informations que vous n'avez pas fournies (veuillez mettre à jour votre question). Par exemple: combien d'objets avez-vous sur votre site? Utilisez-vous beaucoup de gros fichiers? Comment pouvez-vous dire que le goulot d'étranglement des performances est la base de données? –

+0

mis à jour, laissez-moi savoir si l'information est encore clairsemée. J'ai juste la tête autour de Plone. – AndrewMcLagan

+1

@AndrewMcLagan vous pouvez installer https://pypi.python.org/pypi/Products.LongRequestLogger et voir quel est le véritable goulot d'étranglement dans Zope/Plone – gforcada

Répondre

6

Il est hautement improbable que le ZODB lui-même ou la taille de votre base de données soit responsable des mauvaises performances. Je recommande d'emballer votre base de données dans un premier temps. Si vous ne l'avez pas fait cela sur une base régulière avant, l'emballage diminue considérablement la taille de la ZODB:

https://plone.org/documentation/faq/how-do-i-pack-the-zodb

+1

En outre, l'emballage du travail cron nocturne est généralement une bonne idée: http://docs.plone.org/manage/deploying/packing.html - Utilisez le script 'zeopack' pour ZEO ou le script' zodbpack' pour RelStorage. Mes sites utilisent 7 jours d'historique du pack, tous les soirs. – sdupton

+0

Mes premières réflexions étaient avec la base de données relativement peu conventionnelle par rapport aux autres CMS, frameworks et langages. J'ai des sites avec beaucoup moins de ressources, réservant des centaines de fois plus de demandes. Les suggestions pour enquêter sur d'autres cols de bouteilles sont super. Si quelqu'un a d'autres suggestions générales? – AndrewMcLagan

+1

La taille de la BD peut simplement signifier qu'elle n'a pas été emballée. Ou que vous gardez beaucoup d'anciennes versions d'éléments de contenu. Les performances de ZODB ne diminuent pas en particulier avec la taille de Data.fs. – SteveM