Le club : ingénieurs systèmes et réseaux
- 593 réponses
- 25 participants
- 21 787 vues
- 18 followers
will_bru
One Breath III : WBBTMR - One Breath III
"Bunt Magnet strums the strings of nostalgia and sarcasm with equal flair.". Bah quoi ? Y a pas mort d'homme hein...
Anonyme
IBM qui rachète Red Hat, avez-vous un avis cloudhybridé ?
Jimbass
Et les sites de niouses financières semblent découvrir l'existence du logiciel libre ...
Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watts
tobby free
avez-vous un avis cloudhybridé
Les ennemis de mes ennemis sont mes...
y'a pas à tortiller du cul pour chier droit
tobby free
C'est pas que l'open source, c'est mieux, c'est juste que c'est un milieu où le personnel, déjà rincé par une journée de taff, fini sa soirée sur ses projets github
y'a pas à tortiller du cul pour chier droit
tobby free
J'ai remarqué rapidement que le certificat ssl était estampillé amazon. AF a été migré sur AWS? Peut-être que pour une raison que j'ignore, ça n'a strictement aucun rapport.
Mais si oui ? Cela a-t-il un rapport avec les petits problèmes observable de temps à autre ces derniers temps ? Notamment vers 18-19h.
je suis néophyte dans tout ça mais par pure curiosité, je veux bien en savoir un peu plus sur les difficultés que cela peu représenter?
Sur le papier, tout paraît toujours beau mais...
y'a pas à tortiller du cul pour chier droit
.: Odon Quelconque :.
J'ai une question intime au admin d'AF mais pas que.
J'ai remarqué rapidement que le certificat ssl était estampillé amazon. AF a été migré sur AWS?
https://blog.audiofanzine.com/2018/04/audiofanzine-change-dhebergeur/
« What is full of redundancy or formula is predictably boring. What is free of all structure or discipline is randomly boring. In between lies art. » (Wendy Carlos)
tobby free
l'avantage de ce type de plateforme, c'est l'agilité (ce terme me fait toujours rire), vous avez des soucis au départ du à l'architecture sous dimensionné, et il a fallu quelques semaines pour retrouver une situation normale ? C'est pas une critique du tout. Personne n'aime quand ça chie et surtout pas ceux qui bossent dessus. Mais ça a manqué d'agilité ? Je dis ça parce que sur le papier c'est toujours beau. Et aussi parce que j'aimerais bien bosser sur une migration de ce niveau, moi avec mes hyperV et vmware....
y'a pas à tortiller du cul pour chier droit
Anonyme
J'ai un curseur sur une table de la base, qui retourne 210 enregistrements.
Je dois écrire un fichier XML à partir de ces enregistrements : pour chacun d'eux, les valeurs à écrire dans le XML sont tirées de la base, et une dernière doit être lue dans un fichier texte, par ailleurs parfaitement accessible au SGBD (directory déclaré avec les droits kivonbien).
A chaque passe du curseur, ce fichier texte est ouvert, lu, et refermé.
Le seul qui reste constamment ouvert est donc le fichier XML en cours d'écriture.
Ce qu'il se passe : systématiquement à partir du seizième élément et au-delà, le SGBDR refuse obstinément d'ouvrir les fichiers textes...
Obstinément signifie : le 16° fichier existe, comme les 15 précédents (qui ont tous été lus sans aucun problème) et absolument tous les suivants, il est non vide, il est situé au même endroit, dispose des même droits rw-rw-rw et appartient au même propriétaire.
J'ai rusé pour limiter les enregistrements renvoyés par le curseur au 15 et 16° de la liste initiale: ouverture sans aucun souci du fichier 16 qui avait été refusé à la passe précédente, donc, il n'y a pas de problème inhérent au fichier lui-même.
J'ai re-rusé pour renvoyer une autre liste que la liste initiale: "ouverture impossible" à partir systématiquement du 16° fichier ouvert. Quels que soient les enregistrements renvoyés par le curseur, le SGBD refuse toute ouverture à partir du 16° fichier, et tous les autres.
J'ai tenté un FFLUSH du fichier XML en écriture à chaque passe. Aucun effet.
Vous connaîtriez une limite par défaut au nombre de fichier ouverts ?
Je rappelle que ce ne sont pas des ouvertures concurrentes puisque chaque fichier est supposé être ouvert, lu, et refermé avant de passer au suivant.
Merci pour votre aide.
Anonyme
Vous connaîtriez une limite par défaut au nombre de fichier ouverts ?
Si t'es sur un unix like tu peux voir ta limite de descripteurs de fichiers de l'OS (pour ton utilisateur) avec ulimit -n, mais elle est en général assez élevée pour que ça ne cause pas de soucis dans la majorité des cas.
[ Dernière édition du message le 04/07/2019 à 16:25:02 ]
Anonyme
visiblement c'est pas ça... pi là c'est des fichiers ouverts et refermés, et non pas ouvert en concurrence...
m'ci quand même mon denfouchérinet
[ Dernière édition du message le 04/07/2019 à 16:43:41 ]
- < Liste des sujets
- Charte