none
Erreur E_OUTOFMEMORY - OLE DB sur un windows server 2003 multi-processeurs RRS feed

  • Question

  • bonjour à tous

    j'ai des applications ASP.net 3.5 qui se connectent à une base de données serveur SQL Server 2008 via un provider OLE DB. Jusqu'à il y a pas longtemps, ces applications étaient déployées sur un serveur windows 2003 Server (à un seul processeur) et fonctionnaient très bien. Il y a quelques jours, je les ai migrées sur un nouveau serveur windows 2003 Server multi-processeurs (4 je pense), et depuis, j'ai des erreurs aléatoires (je ne comprends pas ce qui les procoque, ni ce qui les corrige) : "'SQLOLEDB' failed with no error message available, result code: E_OUTOFMEMORY(0x800700E)"

    J'en suis à penser que c'est du à OLE DB car quelques modules de mes applications fonctionnent avec le client natif et ces modules fonctionnent sans problème, même lorsque le reste de l'application ne fonctionne pas.

    Vu que la migration de OLE DB est assez délicate, je voudrais savoir s'il y a des solutions qui m'éviteraient d'y recourir.

    PS : la version de MDAC installée est la 2.8 SP2

    Merci
    vendredi 30 octobre 2009 15:02

Toutes les réponses

  • Bonjour,

    J'ai repéré ce phénomène chez des clients suite à des audits et cela dénote le plus souvent un défaut de conception au niveau des données récupérés.

    Lorsque vous avez cette erreur, savez vous quelle sont les requêtes exécutées et le nombre de ligne récupérées ?

    Cordialement
    Gilles TOURREAU - MVP C# - Architecte .NET/Consultant/Formateur
    mardi 3 novembre 2009 22:36
    Modérateur
  • je vais essayer d'explorer cette piste, quoique je n'ai pas eu l'erreur depuis quelques jours

    vous pensiez à quoi par rapport aux requêtes exécutées et au nombre de lignes

    merci !
    mercredi 4 novembre 2009 08:44
  • Bonjour,

    Normalement, pour ne jamais avoir des problèmes de performances au niveau de l'application, il faut absolument qu'à chaque requêtes vous obtenez les informations dont vous avez réellement besoin.
    Par exemple : Dans une application web, on réalise souvent des paginations dans des GridView (où contrôles web similaires).
    Le plus problème que je rencontre le plus fréquemment dans mes audits est le fait que les développeurs récupère toutes la table et la pagine dans le code C#.
    Or en faisant comme çà, vous :
    - 1/Demandez à SQL Server de récupérer une table complète (pour 1000 lignes ca peut faire pas mal de lectures...)
    - 2/SQL Server doit transiter ces résultats sur le réseau vers le serveur web (dans le cas où le serveur SQL n'est pas le même que l'application web) (1000 lignes sont donc transférés).
    - 3/Ces données sont le plus souvent stockés en mémoire (tableau, dataset,...etc), cela consomme donc de la place pour stocker ces lignes (1000 lignes), avec un peu de CPU utilisé. -> Cela peut provoquer des OutOfMemoryException en cas de récupération d'un nombre important de lignes...
    - 4/Ces 1000 lignes en mémoire sont traitées pour récupérer que les 10 ou 20 lignes qui vous interesse (donc temps CPU utilisé).
    - 5/En plus, pendant que votre requête web est en cours de traitement, les autres requêtes web sont en file d'attente (dans le cas d'un serveur mono-processeur).

    En procédant ainsi, on gonfle le temps de traitement d'une requête web. Vous multipliez tout çà par le nombre de visiteurs et le nombre de lignes retournés (1000 dans cette exemple), et vous augmentez de manière exponentielle le temps de traitement de vos requêtes web....

    La solution, est de paginer vos données dans SQL Server (Linq To SQL / Entities fait ca très bien et en une ligne de code !). SQL Server est d'ailleurs conçu pour traiter les données et non les applications web qui doivent se contenter de récupérer les données, les mettre de manière très jolie en HTML et de renvoyer le tout au client.

    Voilà, le genre de problème qui peut se produire si on ne récupère pas réellement les données que l'on a besoin dans SQL Server.
    Une règle à retenir : Si vous souhaitez afficher 20 lignes en HTML --> vous devez récupérer 20 lignes au niveau SQL Server.

    Cordialement
    Gilles TOURREAU - MVP C# - Architecte .NET/Consultant/Formateur
    mercredi 4 novembre 2009 13:07
    Modérateur
  • en fait, ce n'est pas du tout un problème de performances
    la même application a été installé sur un serveur mono-processeur et fonctionnait très bien
    je la migre sur un nouveau serveur beaucoup plus performant, multi-processeurs et j'ai ce problème
    je rappelle que lorsque l'erreur survient, plus aucune application fonctionnant avec OLEDB ne fonctionne plus (sauf des formulaires membership qui eux utilisent le client natif et restent disponibles sans aucune erreur).
    en plus, même en ne faisant aucune tentative pour résoudre le problème (du genre redémarrer la machine...), tout finit par rentrer dans l'ordre qq temps après.

    conclusions :
    - je ne sais pas quelle action provoque le problème (les seuls dénominateurs communs sont : OLE DB et multi-processeur)
    - je ne sais pas quelle action le corrige (le redémarrage de la machine oui !)
    mercredi 4 novembre 2009 14:47