[ SYBASE ] Performance [Résolu]

[6rose]

Bonjour,

Je fais des tests d'insert par une procedure stockées, sur un octo processeur.
Mon but étant de visualiser l'apport du nombre de processeur pour la vitesse d'exécution des requetes.
Ces inserts se font sur une table non partitionnées APL.
Je simule 40 utilisateurs qui lancent chacun 3000 appels à la procédure.
J'effectue le test sur un processeur, puis 2, puis 3 etc jusqu'à 8.

voilà mes résultats :

1 : 887 requetes/s
2 : 870
3 : 1164
4 : 1187
5 : 1164
6 : 1114
7 : 1065
8 : 960

Utilisé 8 processeurs donne de moins bon résultats que 3 et l'accroissement des performances en fonction du nombre de processeur n'est pas énorme.

Est-ce normal?

[fadace]

Oui.

On part generalement du principe de ne pas ajouter d'engine tant qu'elles en passent aps toutes la barre des 80% avec sp_sysmon.
Il faut avoir en tete que le multiprocessoring genere un gros overhead l'optimiseur, par exemple, va calculer plus de choses avec toutes les options qui s'offrent a lui avec le parallelisme. Donc lorsque ce n'est pas necessaire, l'overhead influence negativement les perfs.

Il n'y a pas que le CPU qui travaille : il y a aussi la RAM, le reseau, les disques... Au moment ou tu debloque tout au niveau du CPU, tu peux alors deplacer les goulets sur les autres composants. Dans certains cas de bord, ca peut devenir carrement pejorant.

Ce comportement est l'une des raisons qui a pousse Sybase a permettre l'activation et la desactivation des engines en ligne depuis la version 12.5.0.3. N'oublies pas que le parallelisme est surtout efficace en DSS (gros selects) qu'en OLTP (inserts/updates). Dans ton cas, c'est peut-etre le partitionnement qui pourrait apporter un plus.

Dans ton exemple (et ta config actuelle, tu peux voir que l'optimum se situe a 4 engines. Mais ton test est-il le mirroir de ta production ?

Pour la petite histoire, Oracle avait "attaque" en disant que Sybase ASE ne gerait pas le MPP car avec 64 CPUs, les perf etaient moins bonnes qu'eux. Apres analyse, il s'etait avere que sur l'architecture testee, ASE avec 16 engines battaient allegrement Oracle utiisant les 64 processeurs... mais c'est de bonne guerre... et cela demontre une fois de plus que les test TPC, c'est pas toujours parlant en prod...

[6rose]

En clair, si je ne fais pas que des "gros select" en prod, une machine multi processeurs ne sert à rien !

[fadace]

Non, c'est l'inverse !

- Le parallelisme aide aux gros selects (DSS/decisionnel)
- Le partitionnement limite certains goulet lors de gros inserts (OLTP) et booste le parallelisme (scan parallel degree)

[6rose]

C'est ce que je disais !

Le partitionnement peut vraimens booster les inserts et les updates?
Quel pourcentage?

En fin ce que je remarque c'est est-ce que le rapport nb processeur/performance est il vraiment rentable?
Bref est-ce que cela vaut le coup d'acheter un octo-processeur plutôt qu'un bi-pro où un quadri-pro?

[fadace]

Comme je l'ai dit, c'est un tout. On ne peux pas etre si categorique en perf & tuning.Il faut voir ou sont les goulets pour les resoudres.

Parfois, l'octoprocesseur est limite, parfois il est surdimensionne. L'essentiel c'est que ta machine colle a tes besoins.

Je sais que c'est pas si simple d'obtenir un serveur et on a tendance a gonfler la machine pour les budgets.

Histoire de voir, affiche-moi un sp_showplan "00:01:00" de ta machine en prod, et je te dirai peut-etre ou ca bloque... et je ferai de la decoupe de ce qui n'est pas interessant pour ne pas bourrer le forum avec 1 post monstrueux...

[6rose]

tu veux plutôt dire un sp_sysmon "00:01:00", non?

[fadace]

C'est pas ce que je disais ?
Autant pour moi !
Oui, sp_sysmon avec un temps adapte a ton environnement

[6rose]

je te l'envoie par mail où je crée le plus gros post du forum developpez.com ?

[fadace]

Resume de l'output de ton sp_sysmon

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
Kernel Utilization
------------------
   Engine Busy Utilization 
    Engine 0                       30.3 %                                      
    Engine 1                       32.0 %                                      
    Engine 2                       32.3 %                                      
    Engine 3                       28.5 %                                      
    Engine 4                       27.7 %                                      
    Engine 5                       30.3 %                                      
    Engine 6                       27.2 %                                      
    Engine 7                       28.0 %                                      
  -----------             ---------------          ----------------
  Summary                 Total   236.3 %          Average   29.5 %

Avec aucun CPU a plus de 80%, on peut dire que les CPUs sont sous-utilises. Si ces valeurs n'augmentent jamais, il serait bon meme de baisser le nombre d'engine pour eviter un overhead.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Task Context Switches Due TO:
    Voluntary Yields                  3.2          63.0         189       0.0 %
    Cache Search Misses              37.8         755.0        2265       0.4 %
    System Disk Writes                0.1           2.0           6       0.0 %
    I/O Pacing                        0.0           0.0           0       0.0 %
    Logical LOCK Contention           0.0           0.0           0       0.0 %
    Address LOCK Contention           0.0           0.0           0       0.0 %
    Latch Contention                  0.0           0.0           0       0.0 %
    Log Semaphore Contention          0.0           0.0           0       0.0 %
    PLC LOCK Contention               0.0           0.0           0       0.0 %
    GROUP Commit Sleeps               0.0           0.0           0       0.0 %
    Last Log Page Writes              0.1           1.0           3       0.0 %
    MODIFY Conflicts                  0.0           0.0           0       0.0 %
    I/O Device Contention             0.0           0.0           0       0.0 %
    Network Packet Received         372.7        7453.7       22361       3.9 %
    Network Packet Sent            9134.4      182688.0      548064      95.9 %
    Other Causes                    -26.6        -532.7       -1598      -0.3 %
 
 
Tuning Recommendations FOR Task Management                                    
  ------------------------------------------                                    
  - Consider tuning your Network I/O sub-system

Alors la, il y a un gros probleme. D'habitude, on s'inquiete quand on depasse les 25% ! Ton reseau est sans doute mal configure Retourne-moi l'output de:

Code :

1
2
3
4
5
6
exec sp_configure network
go
SELECT network_pktsz, count(spid) 
FROM sysprocesses 
GROUP BY network_pktsz
go

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Transaction Management
----------------------
 
  ULC Flushes TO Xact Log         per sec      per xact       count  % of total
  -------------------------  ------------  ------------  ----------  ---------- 
    BY Full ULC                       0.0           0.0           0       0.0 %
    BY End Transaction                0.0           0.7           2      22.2 %
    BY CHANGE of DATABASE             0.0           0.0           0       0.0 %
    BY Single Log Record              0.1           1.0           3      33.3 %
    BY Other                          0.1           1.3           4      44.4 %
  -------------------------  ------------  ------------  ----------
  Total ULC Flushes                   0.2           3.0           9    
 
...
 
Tuning Recommendations FOR Transaction Management                             
  -------------------------------------------------                             
  - Consider decreasing the 'user log cache size'
    configuration parameter IF it IS greater than the
    logical DATABASE page size.
 
...
 
 
    Tuning Recommendations FOR DATA cache : DEFAULT DATA cache
    -------------------------------------                                       
    - Consider USING 'relaxed LRU replacement policy' FOR this cache.
    - Consider adding a large I/O pool FOR this cache.

Cree un cache nomme specifique pour les pages de log, en lui attribuant un buffer pool maximum de 4K.
Cree un cache specifique pour tempdb.
Supprime le cache de 8K dans le default data cache
Dans les caches tempdb et default, considere des buffer pools de 80% a 2K et de 20% a 16K. Pas d 8K ni de 4K si les pages de log sont dissociees et liees au log cache avec buffer pool de 4K.
Verifie la taille du ULC via sp_configure "user log cache". Si tu utilises des pages de 2K, il devrait etre a 2048.

[6rose]

voilà :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
Msg 17411, Level 16, State 1:
Procedure 'sp_configure', Line 195:
Configuration OPTION IS NOT UNIQUE.
 
 Parameter Name                 DEFAULT     Memory Used Config Value
	 Run Value   Unit                 Type       
 ------------------------------ ----------- ----------- ------------
	 ----------- -------------------- ---------- 
 additional network memory                0           8        8192 
	        8192 bytes                dynamic    
 DEFAULT network packet size            512        #312         512 
	         512 bytes                static     
 max network packet size                512           0        2048 
	        2048 bytes                static     
 max number network listeners             5         453           5 
	           5 number               static     
 
(1 row affected)
(RETURN STATUS = 1)
 network_pktsz             
 ------------- ----------- 
           512          15 
 
(1 row affected)

[fadace]

Si tu travailles avec de l'Ethernet (dont les paquets sont de 1500), essaie l' option suivante:

Code :

1
2
sp_configure "default network packet", 1024
go

... puis fais en sorte que tes utilisateurs utilisent 1024 comme paquet par defaut (-A1024 pour isql, parametre Performance/Packet Size=2 pour l'ODBC, etc... )

[6rose]

oui j'avais bien un problème réseau, avant de recommencer mes tests, pourrais-tu m'eclaircir ce passage?

Cree un cache nomme specifique pour les pages de log, en lui attribuant un buffer pool maximum de 4K.
Cree un cache specifique pour tempdb.
Supprime le cache de 8K dans le default data cache
Dans les caches tempdb et default, considere des buffer pools de 80% a 2K et de 20% a 16K. Pas d 8K ni de 4K si les pages de log sont dissociees et liees au log cache avec buffer pool de 4K.

[fadace]

http://download.sybase.com/pdfdocs/asg1250f/perf1.pdf
Chapitre 14 (dès page 325)

Que veux-tu exactement savoir ?

[6rose]

bon j'ai essayé de faire comme tu m'as dis mais le problème c'est que mon moteur a par défault des pages de 8k et donc je ne peux pas créer des caches de 4k ou 2k. j'ai donc créé le caches comme tu m'as dis mais avec 8k à la place des 4k et 2k.

les performances n'ont pas vraimens changé...

[fadace]

Desole. Mes commentaire sur les caches partaient d'un serveur a pages de 2K.

Pour du 8K, cache dissocie pour tempdb_cache et log_cache
Log_cache => qu'un buffer pool de 8K
Pour tempdb_cache et default data cache => un mixte de 8 et 16.

Vous etes vraiment dans un environement purement decisionnel ? Pourquoi avoir pris la decision du 8K ? et en APL ? J'imagine alors les problemes de verrous...

[6rose]

Bref,
je me rends compte que j'ai configuré un moteur pour faire du décisionnel, alors que je fais plutôt du transactionnel avec un petit volume de donnée.

d'où mes performances un peu décevantes.

mais bon n'ayant plus beaucoup temps pour mon stage, je m'attaque à la mise en place de l'architecture "cluster" avec repli la semaine prochaine.

[fadace]

On peut clore ?

[6rose]

Il me semble bien que c'est la fin de ce sujet!

merci beaucoup pour ses renseignements qui ont apporté des réponses à mes intérrogations!