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

Sybase Discussion :

[Sybase ASE] Taille des i/o disques


Sujet :

Sybase

  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    16
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 16
    Par défaut [Sybase ASE] Taille des i/o disques
    Bonjour,

    Savez-vous de quelle taille sont les i/o disques réalisé par ASE?

    Est-ce que le taille des i/o est fonction de la taille du buffer mémoire? Par exemple si l'ase travaille en large cache de 16 Ko est-ce que ca joue sur l'i/o disque derriere ou bien l'io reste identique que l'on travaille en buffer memoire de 2Ko ou 16Ko dans le cache?

    Quand le monitoring remonte 500 i/o par seconde comment je calcule les Ko par seconde?

    Merci de vos futures réponses.

  2. #2
    Membre Expert

    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    1 307
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 307
    Par défaut
    La taille des IOs dépendent de la taille de la cache - si les données vont être chargée dans la cache 16k alors Sybase va lire 16k par IO. De même, si on a un serveur configuré en page de 16k alors les IOs peuvent aller de 16k (1 page à la fois) à 128k (8 pages - cad 1 extent - à la fois).

    Pour calculer le nombre d'octets vs. nombres d'IOs on peut utiliser les tables MDA monCachePool, monDataCache, monDeviceIO et éventuellement monProcessActivity. Par example pour monCachePool:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    [129] DBA_SQL.zdb.1> select * from master..monCachePool;
     CacheID     IOBufferSize AllocatedKB PhysicalReads Stalls      PagesTouched PagesRead   BuffersToMRU BuffersToLRU CacheName
     ----------- ------------ ----------- ------------- ----------- ------------ ----------- ------------ ------------ ------------------------------
               0         2048       15360       5468396         286         7326     5468396      5465943  2453 default data cache
               0        16384       15360        743648           0         7637     5949184      5880096 69088 default data cache
     
    (2 rows affected)
    où on compare PhysicalReads et PagesRead.

    Michael

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    16
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 16
    Par défaut
    Merci pour ces explications. Le support semble ommettre la configuration des pools de cache dans sa réponse.

    Donc sur mon serveur dont la taille de page est 2 Ko mes i/o physiques varient entre 2Ko et 16Ko par i/o et je peux me servir de la table monCachePool pour déterminer mon debit.

    Je pose cette question car sur notre nouvelle machine avec une belle baie de disques l'os (AIX 53) nous remonte dans les 30% d'i/o wait.

    Je cherche à déterminer d'où peux venir ce wait mais c'est pas avec 1Mo - 8 Mo /sec que je sature la bestiole... même si tout tombe sur le même disque (on en a 12 en raid 0+1) ca devrait pas générer de wait.

    Par contre notre baie gère par bloc de 512 Ko . Avez-vous dèjà eu ce genre de problèmatique avec des baies de disques?

  4. #4
    Membre Expert

    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    1 307
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 307
    Par défaut
    Attention - il faut faire la différence entre les écritures et les lectures. Les lectures se font en fonction du type d'IO (IO normal - 2k cad page par page) ou "large" IO (16k, extent par extent). Le large IO est utilisé pour les table scans, pour les range scan, et dans quelques autres situations.

    Pour les écritures ce sera en général en 2k, sauf pour la log si on a configuré un pool 4k et qu'on a modifié la taille d'IO pour syslog via sp_logiosize).

    Je suis sous AIX 5.2, baies disque EMC, et je n'ai pas ou très peu de wait. Par contre les applis que j'ai font assez peu d'IOs. J'ai une appli qui reçoit des flux financiers et qui fait en moyenne env. 100 IO par secondes (écritures), et une autre qui est plutôt du DSS et qui fait env 150 IOs/s en écriture, et entre 200 et 1000 IOs/s en lecture). Dans les deux cas je n'ai que peu de wait (rarement plus que 10%) - par contre je ne suis pas l'administrateur système, et je ne sais pas vraiment comment c'est configuré.

    La taille de bloque physique peut évidemment influencer la performance, mais normalement le système de cache de la baie devrait cacher tout cela (dis-je, qui n'a vraiment pas beaucoups de compétences au niveau baies de disques!)

    Michael

  5. #5
    Membre averti
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    16
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 16
    Par défaut
    Merci pour ses précisions.

    On va bientot recevoir une nouvelle baie pour faire des test de configuration j'espere qu'on pourra resoudre ce problème de wait. 30% de wait pour 15% de user et 55% d'idle c'est assez bizarre.

  6. #6
    Membre averti
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    16
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 16
    Par défaut
    J'ai eu un nouveau retour du support technique qui me confirme que la taille des i/o physique dépend seulement de la configuration page du serveur.

    Le large i/o n'est qu'un regroupement en cache l'i/o physique reste directement dépendant de la taille des pages (2K pour moi) car les pages sont chainées entre elles.

  7. #7
    Membre Expert

    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    1 307
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 307
    Par défaut
    Hmmm... je suis assez sur que dans le cas du 16k IO ASE lit 8 pages d'un coup, mais bon, peut-être que je me trompe.

    Michael

  8. #8
    Membre averti
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    16
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 16
    Par défaut
    Bon on va arriver à être tous d'accord.

    Le support vient de m'appeller pour me dire que oui avec le large io c'est du 8 pages d'un coup donc un i/o physique de 16Ko pour des pages en 2Ko

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Sybase ASE, dégradation des performances
    Par ram-0000 dans le forum Adaptive Server Enterprise
    Réponses: 3
    Dernier message: 22/09/2013, 19h14
  2. [2005] Reduire taille des indexes sur disque
    Par cosmos38240 dans le forum Administration
    Réponses: 2
    Dernier message: 04/05/2012, 12h23
  3. Fonctionnement de la taille d'une base sybase ASE
    Par supertom dans le forum Adaptive Server Enterprise
    Réponses: 3
    Dernier message: 05/07/2008, 20h33
  4. [ASE 12.5.3] taille des stripes pour la sauvegarde
    Par dngaya dans le forum Adaptive Server Enterprise
    Réponses: 2
    Dernier message: 18/03/2008, 12h26

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