Sitzungen werden nach kurzer Zeit im 64-Bit-Anwendungspool beendet

8

Wir haben eine .net-Webanwendung auf IIS 7.5 gehostet. Früher lief diese Anwendung in einem 32-Bit-Anwendungspool, aber vor einiger Zeit haben wir in den 64-Bit-Anwendungspool gewechselt.

In letzter Zeit haben sich Benutzer darüber beschwert, dass ihre Sitzung nach 1-2 Minuten Leerlauf beendet wird, was wir heute bestätigt haben.

In der Datei web.config ist das Sitzungszeitlimit auf 60 Minuten festgelegt. Außerdem haben wir im Task-Manager festgestellt, dass der w3wp-Prozess für diese Anwendung etwa 2-2,4 GB Arbeitsspeicher verbraucht. Das Problem ist also möglicherweise, dass der Anwendungspool versucht, etwas Arbeitsspeicher zu recyceln?

Das Recycling ist auf begrenzte Zeiträume von 21:00 und 4:00 Uhr festgelegt.

Was könnte der Grund für diese Probleme mit Sitzungen sein?

BEARBEITEN:

Ich habe einige Zähler überprüft und die grundlegende Speicherauszugsanalyse durchgeführt, aber ich sehe keine Probleme.

Im dump eeheap analysis sehe ich nur Objekte der Generation 2 von 10-30MB für jeden Haufen und ich habe 24 davon

Heap 0 (0000000003083a90) Generation 0 beginnt bei 0x00000000fff568b8 Generation 1 beginnt bei 0x00000000ffa6acf0 Generation 2 beginnt bei 0x00000000ff471000 ephemere Segmentzuordnung Kontext: kein Segment beginnt zugeordnete Größe 00000000ff470000 00000000ff471000 00000000ffff8de0 0xb87de0 (12090848) Großer Objektspeicher beginnt bei 0x00000006ff471000 Segment beginnt zugeordnete Größe 00000006ff470000 00000006ff471000 00000006ff7495c8 0x2d85c8 (2983368) Heap-Größe: Größe: 0xe603a8 (15074216) Bytes.

Heap 1 (00000000030889c0) Generation 0 beginnt bei 0x000000013fc36ed8 Generation 1 beginnt bei 0x000000013f949348 Generation 2 beginnt bei 0x000000013f471000 ephemere Segmentzuweisungskontext: kein Segment beginnt zugewiesene Größe 000000013f470000 000000013f471000 000000014035e7b8 0xeed7b8 (15652792) Großer Objektspeicher beginnt bei 0x0000000703471000 Segment beginnt zugeordnete Größe 0000000703470000 0000000703471000 00000007035c5d58 0x154d58 (1396056) Heapgröße: Größe: 0x1042510 (17048848) Byte.

BEARBEITEN: 2015-08-19 09:00 Das sind die Zähler für 09:00 2015-08-19

Was mich beunruhigt ist, warum der Speicher im Task-Manager 2,5 GB anzeigt, wenn die Bytes in allen Heaps nur etwa 100 MB anzeigen und warum die privaten Bytes (216 MB) in allen Heaps größer sind als Bytes? Die Last in diesem Moment ist ungefähr 40 Benutzer auf diesem Server.

BEARBEITEN 2015-08-19 14:09

Nach einiger Zeit sehe ich, dass es ein Problem mit Baugruppen geben könnte. Wie kann ich dies mit windbg überprüfen, wenn ich auf .NET 4.5 bin, wo es keinen! Dda Befehl gibt?

    
shin 11.08.2015, 20:21
quelle

1 Antwort

0

Versuchen Sie, die laufende App in einen anderen Pool zu kopieren, deaktivieren Sie in diesem neuen jedoch alle Assemblys / Referenzen, die Sie nicht benötigen, um zu sehen, was Sie tun.

Wie Sie sagten, denke ich, dass ein Assembler Ihren Anwendungspool zum Absturz bringt, vielleicht, weil er vielleicht nicht 64 Bit unterstützt.

Versuchen Sie, alle nicht verwendeten Referenzen zu deaktivieren, alle zu aktualisieren usw.

    
Flávio Rodrigues 24.08.2015 12:51
quelle

Tags und Links