Too many data in table connexions

[Frédéric Sheedy]

Je voulais rapporter quelques difficultés que nous avons encourus, et dont une solution serait surement utile à tous.

En 4 mois d'utilisation, le tableau connexions a augmenté à 100,000 entrées, 55 MB. Étant la nature du logiciel, chaque minute le serveur reçoit des appels de tous les routeurs qui performent des requêtes full-scan chacunes ce qui causait une utilisation de ressources trop élevée.

Pour comparer, la base de données wifidog n'a jamais dépassé les 200 megs au complet incluant le contenu après les 5 années d'utilisation. Je pense que le tableau "connexions" se balonne trop rapidement, et deviens un point de pression du logiciel.

Une proposition que j'aurais serait de mettre en place de l'archivage automatique, c'est à dire que les vieilles entrées qui n'ont pas besoin d'être visitées à chaque requêtes soient déplacée dans une table à part pour que la table "live" soit toujours légère et rapide.

Ma solution pour le moment est de transvider la table connexions à chaque 2 mois pour que cette dernière reste toujours légère.

[Frédéric Sheedy (fsheedy)]

Description of the bug from question #194651 (Wadih).

[gbastien (gbastien02)]

Ce serait pas juste un index manquant ou mal configuré? Car dans l'ancien serveur wifidog, c'était pareil et ça ne posait pas de problème...

Il y a certains champs qu'on garde maintenant qu'on ne gardait pas dans wifidog comme le user agent, qui peut expliquer la taille plus grande de la BD, mais ça ne devrait pas affecter les performances.

[Wadih (wadih)]

Merci de ta réponse.

J'ai vérifié ça en premier mais les index étaient en place et fonctionnels. J'ai attaché une capture d'écran. J'ai également essayé de faire un mysql optimize mais sans amélioration.

Dans les faits, je peux vous assurer de première main que le serveur rushait et usait toute sa mémoire. Le tout c'est réglé quand j'ai transvidé la table connexions dans une nouvelle table backup.

Est-ce que authpuppy utilises beaucoup de requêtes "select *", celles-ci sont mortelles dans des scénarios comme celui là. Surtout quand c'est un tableau qui mesure 55 MB, un full table scan prendra une quantité considérable de mémoire.

Un autre détail est que cette table a atteint 55 MB en 4 mois pour un serveur à relativement faible traffic (60 points d'accès). C'est bien trop, en 5 ans avec wifidog la base de données entière n'a jamais dépassé 200 megs au total. Peut-être il y a une fuite de données qui cause certaines entrées à ne jamais s'effacer ou à s'ajouter en double, ou il faut simplement révisier ce qui est enregistré.

Je peux exporter la base de données pour analyze.

Wadih

[gbastien (gbastien02)]

En fait, je pensais à un index manquant ou mal configuré dans Authpuppy et non dans ta BD en particulier.

Je ne pense pas que la performance des requêtes a été optimisée dans le développement, alors il y a du travail à faire là-dessus. Je vais essayer de faire un peu de profilage et trouver ce qui cloche, dès que j'ai un peu de temps. D'ici là Wadih si tu trouves la ou les requêtes qui demandent tant de ressources, laisse-nous savoir.

[Wadih (wadih)]

Merci Genevieve

Quand mon serveur rushait, je regardais l'onglet Processes sur phpmyadmin (equivalent à la commande SHOW PROCESSLIST dans mysql), et les requêtes s'accumulaient et ne se terminaient pas. Je n'ai malheureusement pas pris à ce moment de capture d'écran des requêtes problèmatiques.

Depuis que j'ai transvidé la table, toutes les requêtes se terminent en moins d'une seconde quand je surveille show processlist.

Je vais garder un oeil dessus aussi et ajouter de l'info quand j'en aurais.

Concernant les 55 mb de grosseur, à ce taux elle va grossir de 220 megs par année. Je pense que je vais simplement garder 1 année de données dans mes backups, sinon les choses vont prendre trop d'espace.

[jackson (neojack34-isf)]

Salut Wahid,

dans ton premier message tu dis "Étant la nature du logiciel, chaque minute
le serveur
reçoit des appels de tous les routeurs qui performent des requêtes full-
scan chacunes ce qui causait une utilisation de ressources trop élevée."

Effectivement, on a eu ce problème aussi qui peut s’apparenter à un genre
de DoS

Nous avons trouvé une solution de contournement en changeant le fichier
wifidog.conf de tous nos nouveaux routeurs (et des anciens que l'on met à
jour quand on peut) :

dans wifidog.conf, il y a une variable "checkinterval" qui par défaut est à
120 secondes. Ce qui veut dire que le routeur fait une requette toutes les
deux minutes au serveur.
Si tu met cette valeur à 900, la requete ne sera que toutes les 15 minutes,
ce qui divise la charge serveur par 7,5 pour un nombre de routeurs égal !

Cordialement
Jackson JOSEPH-EUGENE
Coordinateur technique et des bénévoles Ile Sans Fil

Le 4 mai 2012 14:34, Wadih <email address hidden> a écrit :

> Merci Genevieve
>
> Quand mon serveur rushait, je regardais l'onglet Processes sur
> phpmyadmin (equivalent à la commande SHOW PROCESSLIST dans mysql), et
> les requêtes s'accumulaient et ne se terminaient pas. Je n'ai
> malheureusement pas pris à ce moment de capture d'écran des requêtes
> problèmatiques.
>
> Depuis que j'ai transvidé la table, toutes les requêtes se terminent en
> moins d'une seconde quand je surveille show processlist.
>
> Je vais garder un oeil dessus aussi et ajouter de l'info quand j'en
> aurais.
>
> Concernant les 55 mb de grosseur, à ce taux elle va grossir de 220 megs
> par année. Je pense que je vais simplement garder 1 année de données
> dans mes backups, sinon les choses vont prendre trop d'espace.
>
> --
> You received this bug notification because you are subscribed to
> AuthPuppy.
> https://bugs.launchpad.net/bugs/990215
>
> Title:
> Too many data in table connexions
>
> Status in AuthPuppy authentication server for Wifidog networks:
> Confirmed
>
> Bug description:
> Je voulais rapporter quelques difficultés que nous avons encourus, et
> dont une solution serait surement utile à tous.
>
> En 4 mois d'utilisation, le tableau connexions a augmenté à 100,000
> entrées, 55 MB. Étant la nature du logiciel, chaque minute le serveur
> reçoit des appels de tous les routeurs qui performent des requêtes
> full-scan chacunes ce qui causait une utilisation de ressources trop
> élevée.
>
> Pour comparer, la base de données wifidog n'a jamais dépassé les 200
> megs au complet incluant le contenu après les 5 années d'utilisation.
> Je pense que le tableau "connexions" se balonne trop rapidement, et
> deviens un point de pression du logiciel.
>
> Une proposition que j'aurais serait de mettre en place de l'archivage
> automatique, c'est à dire que les vieilles entrées qui n'ont pas
> besoin d'être visitées à chaque requêtes soient déplacée dans une
> table à part pour que la table "live" soit toujours légère et rapide.
>
> Ma solution pour le moment est de transvider la table connexions à
> chaque 2 mois pour que cette dernière reste toujours légère.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/authpuppy/+bug/...

[Marc Boivin (marcboivin)]

Ici, les seules requêtes qui sont problématique sont celles pour les statistiques.

Nous pouvons partager notre setup du stack software, parce que c'est vraiment ça qui fait la différence. Notre serveur supporte 400 bornes + les demandes de connexions et ils dors au gaz.

Marc

Sent from my iPhone

On 2012-05-04, at 3:14 PM, jackson <email address hidden> wrote:

> Salut Wahid,
>
> dans ton premier message tu dis "Étant la nature du logiciel, chaque minute
> le serveur
> reçoit des appels de tous les routeurs qui performent des requêtes full-
> scan chacunes ce qui causait une utilisation de ressources trop élevée."
>
> Effectivement, on a eu ce problème aussi qui peut s’apparenter à un genre
> de DoS
>
> Nous avons trouvé une solution de contournement en changeant le fichier
> wifidog.conf de tous nos nouveaux routeurs (et des anciens que l'on met à
> jour quand on peut) :
>
> dans wifidog.conf, il y a une variable "checkinterval" qui par défaut est à
> 120 secondes. Ce qui veut dire que le routeur fait une requette toutes les
> deux minutes au serveur.
> Si tu met cette valeur à 900, la requete ne sera que toutes les 15 minutes,
> ce qui divise la charge serveur par 7,5 pour un nombre de routeurs égal !
>
>
> Cordialement
> Jackson JOSEPH-EUGENE
> Coordinateur technique et des bénévoles Ile Sans Fil
>
> Le 4 mai 2012 14:34, Wadih <email address hidden> a écrit :
>
>> Merci Genevieve
>>
>> Quand mon serveur rushait, je regardais l'onglet Processes sur
>> phpmyadmin (equivalent à la commande SHOW PROCESSLIST dans mysql), et
>> les requêtes s'accumulaient et ne se terminaient pas. Je n'ai
>> malheureusement pas pris à ce moment de capture d'écran des requêtes
>> problèmatiques.
>>
>> Depuis que j'ai transvidé la table, toutes les requêtes se terminent en
>> moins d'une seconde quand je surveille show processlist.
>>
>> Je vais garder un oeil dessus aussi et ajouter de l'info quand j'en
>> aurais.
>>
>> Concernant les 55 mb de grosseur, à ce taux elle va grossir de 220 megs
>> par année. Je pense que je vais simplement garder 1 année de données
>> dans mes backups, sinon les choses vont prendre trop d'espace.
>>
>> --
>> You received this bug notification because you are subscribed to
>> AuthPuppy.
>> https://bugs.launchpad.net/bugs/990215
>>
>> Title:
>> Too many data in table connexions
>>
>> Status in AuthPuppy authentication server for Wifidog networks:
>> Confirmed
>>
>> Bug description:
>> Je voulais rapporter quelques difficultés que nous avons encourus, et
>> dont une solution serait surement utile à tous.
>>
>> En 4 mois d'utilisation, le tableau connexions a augmenté à 100,000
>> entrées, 55 MB. Étant la nature du logiciel, chaque minute le serveur
>> reçoit des appels de tous les routeurs qui performent des requêtes
>> full-scan chacunes ce qui causait une utilisation de ressources trop
>> élevée.
>>
>> Pour comparer, la base de données wifidog n'a jamais dépassé les 200
>> megs au complet incluant le contenu après les 5 années d'utilisation.
>> Je pense que le tableau "connexions" se balonne trop rapidement, et
>> deviens un point de pression du logiciel.
>>
>> Une proposition que j'aurais serait de met...

[dgpelletier (dgpelletier)]

Ou s'endore et paralyse cerebralement?

Dave G.Pelletier
ZAP Québec
418.263.8020

Envoyé de mon indispensable iPhone du réseau ZAP Québec

Le 2012-05-05 à 08:21, Marc Boivin <email address hidden> a écrit :

> Ici, les seules requêtes qui sont problématique sont celles pour les
> statistiques.
>
> Nous pouvons partager notre setup du stack software, parce que c'est
> vraiment ça qui fait la différence. Notre serveur supporte 400 bornes +
> les demandes de connexions et ils dors au gaz.
>
> Marc
>
> Sent from my iPhone
>
> On 2012-05-04, at 3:14 PM, jackson <email address hidden> wrote:
>
>> Salut Wahid,
>>
>> dans ton premier message tu dis "Étant la nature du logiciel, chaque minute
>> le serveur
>> reçoit des appels de tous les routeurs qui performent des requêtes full-
>> scan chacunes ce qui causait une utilisation de ressources trop élevée."
>>
>> Effectivement, on a eu ce problème aussi qui peut s’apparenter à un genre
>> de DoS
>>
>> Nous avons trouvé une solution de contournement en changeant le fichier
>> wifidog.conf de tous nos nouveaux routeurs (et des anciens que l'on met à
>> jour quand on peut) :
>>
>> dans wifidog.conf, il y a une variable "checkinterval" qui par défaut est à
>> 120 secondes. Ce qui veut dire que le routeur fait une requette toutes les
>> deux minutes au serveur.
>> Si tu met cette valeur à 900, la requete ne sera que toutes les 15 minutes,
>> ce qui divise la charge serveur par 7,5 pour un nombre de routeurs égal !
>>
>>
>> Cordialement
>> Jackson JOSEPH-EUGENE
>> Coordinateur technique et des bénévoles Ile Sans Fil
>>
>> Le 4 mai 2012 14:34, Wadih <email address hidden> a écrit :
>>
>>> Merci Genevieve
>>>
>>> Quand mon serveur rushait, je regardais l'onglet Processes sur
>>> phpmyadmin (equivalent à la commande SHOW PROCESSLIST dans mysql), et
>>> les requêtes s'accumulaient et ne se terminaient pas. Je n'ai
>>> malheureusement pas pris à ce moment de capture d'écran des requêtes
>>> problèmatiques.
>>>
>>> Depuis que j'ai transvidé la table, toutes les requêtes se terminent en
>>> moins d'une seconde quand je surveille show processlist.
>>>
>>> Je vais garder un oeil dessus aussi et ajouter de l'info quand j'en
>>> aurais.
>>>
>>> Concernant les 55 mb de grosseur, à ce taux elle va grossir de 220 megs
>>> par année. Je pense que je vais simplement garder 1 année de données
>>> dans mes backups, sinon les choses vont prendre trop d'espace.
>>>
>>> --
>>> You received this bug notification because you are subscribed to
>>> AuthPuppy.
>>> https://bugs.launchpad.net/bugs/990215
>>>
>>> Title:
>>> Too many data in table connexions
>>>
>>> Status in AuthPuppy authentication server for Wifidog networks:
>>> Confirmed
>>>
>>> Bug description:
>>> Je voulais rapporter quelques difficultés que nous avons encourus, et
>>> dont une solution serait surement utile à tous.
>>>
>>> En 4 mois d'utilisation, le tableau connexions a augmenté à 100,000
>>> entrées, 55 MB. Étant la nature du logiciel, chaque minute le serveur
>>> reçoit des appels de tous les routeurs qui performent des requêtes
>>> full-scan chacunes ce qui causait une utilisation de ressources trop
>>> élevée.
>>>
>>> Pour com...

[Wadih (wadih)]

Jackson, merci de ton idée c'est une façon de réduire le chargement au prix d'une résponsivité moins haute, mais ça demanderais beaucoup de déplacements (au moins pour les routeurs inaccessibles à l'externe). Le problème continuerait d'exister, mais se manifesterais moins.

Marc, pourrais-tu développer un peu plus en détail ? Tu veux dire que tu copies les données quelque part d'autre et génère les statistiques de là bas ?

Wadih