Se connecter
Se connecter

ou
Créer un compte

ou

Le club : ingénieurs systèmes et réseaux

  • 593 réponses
  • 25 participants
  • 21 787 vues
  • 18 followers
Sujet de la discussion Le club : ingénieurs systèmes et réseaux
Voilà, pour pas polluer les Noobs avec des acronymes à coucher dehors, welcome à tous les IT managers et autres ingés/techs, qui nagent dans les bits et les protocoles à longueur de journée.

:bravo:

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...

Afficher le sujet de la discussion
521
Bref.

IBM qui rachète Red Hat, avez-vous un avis cloudhybridé ?
522
Hmmm, ils ont cassé leur tirelire.

Et les sites de niouses financières semblent découvrir l'existence du logiciel libre ...
523
Citation :
avez-vous un avis cloudhybridé

Les ennemis de mes ennemis sont mes...

y'a pas à tortiller du cul pour chier droit

524
Si je dis pas de bêtises, AWS repose sur des infras typées open source.
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

525
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? 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

526
Citation de tobby :
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/

:-D

« 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)

527
Ok effectivement c'est pas d'aujourd'hui mais c'est pas si vieux. Merci pour la réponse.
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

528
Des ingénieurs SGBD Oracle dans la salle ?

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.
529
Citation :
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 ]

530
ulimit -n = 1024
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 ]