64 bit Version of all Solarwinds products

How about a Linux based Appliance that allows you to add on features with unlock codes.  64 bit of course.

It's never gonna happen, but I liked your comment anyway. A guy can dream...

My business-layer aka moduleengine died regularly because it hits the 2GB limit, at least until I got YABD last week.

/RjL

YABD: Yet-Another-Buddy-Drop

That sounds like a memory leak issue. A 64bit Module Engine process would simply have let the process leak further. While I don't think anyone is opposed to the idea of a 64bit version of Orion. In fact the Job Engine is already 64bit as anyone with SAM can see by editing any assigned application, expanding the "Advanced" section, and selecting x64 job processing. This tells the job to use the 64bit Job Engine instead of the 32bit Job Engine. This option exists and defaults to x86 (32bit) because not all jobs can be executed properly in a 64bit processes. E.G. Calling 32bit PowerShell cmdlets is a good example, or opening an ODBC connection that relies on a 32bit ODBC driver.

This is unfortunately misguided. 64-bit Native can (and almost always) does provide a significant performance improvement.

• First off, WOW64 consumes additional cycles when you run a 32-bit process in windows on a 64-bit native machine.
• We have a network with over 3000 routers, 14k switches, and I cant even banter a guess at servers, vms, and clients. We have 16 pollers that consistently consume 1.8 GB of RAM. Instead of being able to scale a single VM, we must license multiple polling nodes to accommodate the limits of 32-bit Orion. Which don't get me wrong.. its still cheap, and hence not a big deal. But there are other costs such as the software and agents that have to run side by side on those VMs for information security, logging, etc.
• Remember, Microsoft is showing you unpaged memory consumption in the view you're looking at. If you really want to see the performance hit you're taking by running 32-bit. Look at the Quantity of Page Faults. What we noticed was as we scaled the quantity of nodes on a single instance, the memory footprint would not increase, but the Page Fault count increased dramatically. Eventually the Page Faults would begin to plane off and the Working Set (Memory consumption) would begin to increase. I'm sure this has to do with how Windows handles memory management.
• On that same note, we have a similar product that we use for netflow management (as Orion's Netflow product scales horribly) and we had a similar experience. (Performance degraded with Page Faults, until a process began increasing its footprint in the Working Set. When we migrated the 3rd party's Netflow product to the 64-bit platform, page-faults dropped to nearly inconsequential levels. The Working Set (Memory) consumption inside of windows increased dramatically, and low and behold the performance of the application was dramatically increased. Reports that took 2 hours to pull prior took minutes.

I don't envy the Orion/Solwarinds Team. I'm sure they have quite a task ahead of them. Not just in migrating to 64-bit, but the bugs and issues that will result due to the migration. But I honestly can't be happier that this will happen and am thankful for their commitment. What I really want and it doesn't seem to be posted anywhere is a target date/version.

Not to mention we have a server with 40 logical processors which causes problems for 32 bit apps running on 64bit OS. This is a known issue that first came out in 2008 server but still exists in 2012 server, though they did have a hotfix for 2008, not sure about 2012 still looking since that is what we run currently.  You get the error listed in microsoft link below. So i agree, a push to 64 bit solarwinds products will be quite a task but i believe is necessary.

https://support.microsoft.com/en-us/help/2279566/32-bit-application-cannot-query-performance-server-work-queues-counter

spx13320​, the issue you are describing was resolved in Orion Platform 2017.3 which shipped with NPM 12.2.

spx13320​, the issue you are describing was resolved in Orion Platform 2017.3 which shipped with NPM 12.2.

Orion Platform 2017.3 also shipped with SAM 6.5.