# Verwenden Sie immer die 64-Bit-Architektur mit IronOCR
IronOCR führt speicherintensive Arbeiten im Hintergrund aus, daher stößt ein 32-Bit (x86)-Build an die ~2GB Speichergrenze und beginnt zu scheitern bei großen oder hochvolumigen Dokumenten. Das Ziel, 64-Bit (x64) einzusetzen, ist die Lösung.
Ein 32-Bit-Prozess ist unabhängig davon, wie viel RAM die Maschine hat, auf etwa 2GB nutzbaren Speicher begrenzt. Unter dieser Grenze tauchen OCR-Arbeiten häufig wie folgt auf:
```txt
System.OutOfMemoryException
```
Andere Symptome der gleichen Grenze sind Deadlocks während der Ausführung der OCR-Engine, Ressourcenverknappung bei der Bildvorverarbeitung, Abstürze oder nicht behandelte Ausnahmen und OCR-Ergebnisse, die time-out sind oder unbemerkt scheitern.
Der Druck kommt von den Operationen, die IronOCR pro Dokument ausführt: hochauflösende Bilddarstellung, temporäre Rastern, optische Zeichenerkennung und tiefe Textextraktion mit einem maschinellen Lernmodell (verwendet von den `AdvancedScan`-Methoden und `SearchablePDF`-Ausgabe). Jede davon kann Hunderte von MB pro Dokument verlangen, und mehrseitige PDFs, mehrseitige TIFFs und 300+ DPI-Bilder treiben das nach oben.
[[i:(IronOCR ruft auch native Bibliotheken für OCR, Bilddarstellung und PDF-Rastern auf. Diese allokieren nicht verwalteten Speicher, den der .NET-Garbage-Collector nicht sehen kann, was noch mehr Druck in einem 32-Bit-Prozess addiert.)]]
## Lösung
### Option 1: Setzen Sie das Plattformziel in Visual Studio
Wechseln Sie das Projekt auf x64 über die Build-Einstellungen:
1. Klicken Sie mit der rechten Maustaste auf Ihr Projekt und öffnen Sie **Eigenschaften**.
2. Öffnen Sie die Registerkarte **Build**.
3. Setzen Sie **Plattformziel** auf `x64`.
4. Lassen Sie **Bevorzugen 32-Bit** deaktiviert.
### Option 2: Setzen Sie das Ziel über die CLI oder .csproj
Veröffentlichen Sie gegen eine 64-Bit-Laufzeit, um die Architektur zur Build-Zeit zu erzwingen:
```bash
dotnet publish -c Release -r win-x64
```
Oder pinnen Sie das Ziel direkt in Ihrem `.csproj` fest:
```xml
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
```
Die `<Prefer32Bit>false</Prefer32Bit>`-Zeile spielt eine Rolle, wenn das Projekt `AnyCPU` ist: mit ihr aktiviert, startet die App trotzdem als 32-Bit-Prozess und übernimmt die gleiche Grenze.
[[w:(Vermeiden Sie "AnyCPU" mit "Bevorzugen 32-Bit" aktiviert. Es führt stillschweigend die 2GB-Beschränkung wieder ein, selbst auf einer 64-Bit-Maschine.)]]
## Wann die Architektur verdächtigt werden soll
Überprüfen Sie die Architektur zuerst, wenn Sie OCR-Jobs sehen, die hängen oder unerwartet abstürzen, intermittierende Speicherplatz-Ausnahmen oder Leistungsabbau bei hochvolumigen Dokumenten. Wenn Sie auf x86 laufen, wechseln Sie zu x64, bevor Sie etwas anderes untersuchen.
Behalten Sie einige Gewohnheiten in der Produktion:
- **Ziel auf x64 für die Produktion:** es ist die einzige unterstützte Konfiguration für schwere OCR-Arbeitslasten.
- **Entwickeln Sie auf x64:** Tests auf x64 spiegeln reales Speicherverhalten wider und bringen Probleme frühzeitig ans Licht.
- **64-Bit Docker-Images erstellen:** Stellen Sie sicher, dass das Basis-Image `linux/amd64` ist.
Beachten Sie, dass gleichzeitige OCR-Vorgänge den Speicher schnell ansteigen lassen. Auch bei kleinen Dokumenten können Multithread- oder asynchrone Operationen schnell ansteigen.
## Wenn Sie die Architektur nicht ändern können
Wenn x64 keine Option ist, teilen Sie große Dokumente in kleinere Abschnitte auf und verarbeiten Sie sie mit niedrigerer Auflösung. Erwarten Sie einen Kompromiss bei Leistung und Genauigkeit. Stabile Unterstützung für 32-Bit-Projekte wird derzeit untersucht.
IronOCR führt speicherintensive Arbeiten im Hintergrund aus, daher stößt ein 32-Bit (x86)-Build an die ~2GB Speichergrenze und beginnt zu scheitern bei großen oder hochvolumigen Dokumenten. Das Ziel, 64-Bit (x64) einzusetzen, ist die Lösung.
Ein 32-Bit-Prozess ist unabhängig davon, wie viel RAM die Maschine hat, auf etwa 2GB nutzbaren Speicher begrenzt. Unter dieser Grenze tauchen OCR-Arbeiten häufig wie folgt auf:
System.OutOfMemoryException
System.OutOfMemoryException
Text
Andere Symptome der gleichen Grenze sind Deadlocks während der Ausführung der OCR-Engine, Ressourcenverknappung bei der Bildvorverarbeitung, Abstürze oder nicht behandelte Ausnahmen und OCR-Ergebnisse, die time-out sind oder unbemerkt scheitern.
Der Druck kommt von den Operationen, die IronOCR pro Dokument ausführt: hochauflösende Bilddarstellung, temporäre Rastern, optische Zeichenerkennung und tiefe Textextraktion mit einem maschinellen Lernmodell (verwendet von den AdvancedScan-Methoden und SearchablePDF-Ausgabe). Jede davon kann Hunderte von MB pro Dokument verlangen, und mehrseitige PDFs, mehrseitige TIFFs und 300+ DPI-Bilder treiben das nach oben.
Hinweis:: IronOCR ruft auch native Bibliotheken für OCR, Bilddarstellung und PDF-Rastern auf. Diese allokieren nicht verwalteten Speicher, den der .NET-Garbage-Collector nicht sehen kann, was noch mehr Druck in einem 32-Bit-Prozess addiert.
Lösung
Option 1: Setzen Sie das Plattformziel in Visual Studio
Wechseln Sie das Projekt auf x64 über die Build-Einstellungen:
Klicken Sie mit der rechten Maustaste auf Ihr Projekt und öffnen Sie Eigenschaften.
Öffnen Sie die Registerkarte Build.
Setzen Sie Plattformziel auf x64.
Lassen Sie Bevorzugen 32-Bit deaktiviert.
Option 2: Setzen Sie das Ziel über die CLI oder .csproj
Veröffentlichen Sie gegen eine 64-Bit-Laufzeit, um die Architektur zur Build-Zeit zu erzwingen:
dotnet publish -c Release -r win-x64
dotnet publish -c Release -r win-x64
SHELL
Oder pinnen Sie das Ziel direkt in Ihrem .csproj fest:
Die <Prefer32Bit>false</Prefer32Bit>-Zeile spielt eine Rolle, wenn das Projekt AnyCPU ist: mit ihr aktiviert, startet die App trotzdem als 32-Bit-Prozess und übernimmt die gleiche Grenze.
Warnung: Vermeiden Sie "AnyCPU" mit "Bevorzugen 32-Bit" aktiviert. Es führt stillschweigend die 2GB-Beschränkung wieder ein, selbst auf einer 64-Bit-Maschine.
Wann die Architektur verdächtigt werden soll
Überprüfen Sie die Architektur zuerst, wenn Sie OCR-Jobs sehen, die hängen oder unerwartet abstürzen, intermittierende Speicherplatz-Ausnahmen oder Leistungsabbau bei hochvolumigen Dokumenten. Wenn Sie auf x86 laufen, wechseln Sie zu x64, bevor Sie etwas anderes untersuchen.
Behalten Sie einige Gewohnheiten in der Produktion:
Ziel auf x64 für die Produktion: es ist die einzige unterstützte Konfiguration für schwere OCR-Arbeitslasten.
Entwickeln Sie auf x64: Tests auf x64 spiegeln reales Speicherverhalten wider und bringen Probleme frühzeitig ans Licht.
64-Bit Docker-Images erstellen: Stellen Sie sicher, dass das Basis-Image linux/amd64 ist.
Beachten Sie, dass gleichzeitige OCR-Vorgänge den Speicher schnell ansteigen lassen. Auch bei kleinen Dokumenten können Multithread- oder asynchrone Operationen schnell ansteigen.
Wenn Sie die Architektur nicht ändern können
Wenn x64 keine Option ist, teilen Sie große Dokumente in kleinere Abschnitte auf und verarbeiten Sie sie mit niedrigerer Auflösung. Erwarten Sie einen Kompromiss bei Leistung und Genauigkeit. Stabile Unterstützung für 32-Bit-Projekte wird derzeit untersucht.
Curtis Chau hat einen Bachelor-Abschluss in Informatik von der Carleton University und ist spezialisiert auf Frontend-Entwicklung mit Expertise in Node.js, TypeScript, JavaScript und React. Leidenschaftlich widmet er sich der Erstellung intuitiver und ästhetisch ansprechender Benutzerschnittstellen und arbeitet gerne mit modernen Frameworks sowie der Erstellung gut strukturierter, optisch ansprechender Handbücher.
