Discussions
Categories
- 197K All Categories
- 2.5K Data
- 546 Big Data Appliance
- 1.9K Data Science
- 450.8K Databases
- 221.9K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 552 MySQL Community Space
- 479 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.1K ORDS, SODA & JSON in the Database
- 556 SQLcl
- 4K SQL Developer Data Modeler
- 187.2K SQL & PL/SQL
- 21.4K SQL Developer
- 296.4K Development
- 17 Developer Projects
- 139 Programming Languages
- 293.1K Development Tools
- 111 DevOps
- 3.1K QA/Testing
- 646.1K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 161 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.2K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 19 Java Essentials
- 162 Java 8 Questions
- 86K Java Programming
- 81 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 205 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 475 LiveLabs
- 39 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 175 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 233 Portuguese
Oracle.DataAccess.Client.OracleException (0x80004005): Memory could not be allocated
Answers
-
That was my thought as well (that it had to be a client issue) but I figured I'd double-check.
I've been doing some preliminary memory profiling, and it does look like the application might be skirting quite close to that 2gb limit. I need to delve in more detail to find out why - the managed part of the code is using only a small portion of that, and it doesn't have the classic profile of a memory leak, but in the meantime any ways to work around that would be welcome. I've been reading up about the /3GB system switch though, and everything I've read implies that it doesn't do anything on a 64-bit OS; I should be clear that the app is stuck as 32-bit, but the OS of the servers is 64-bit.
EDIT: Found some info about the /LARGEADDRESSAWARE compiler flag, that seems like it might help. I'll give that a try.
-
Yes, you're right about /3GB. That was an option for apps on 32-bit OSes since 1 of those GBs was being taken from the OS to use. It's been awhile since I've dealt with any 32-bit specific limitations. The /LARGEADDRESSAWARE is for 32-bit apps on 64-bit OSes. Theoretically, it would appear that it would give a 32-bit app more memory without robbing from 64-bit OS resources.
-
I've proved to myself that it is indeed the 2GB limit for 32-bit processes that is causing the memory error, so I'm going to call this solved, and leave it here in case someone else finds it useful.
Haven't yet worked out where the memory leak in our code is, but that's not really Oracle's problem...