Open for Voting
over 1 year ago

64 bit Version of all Solarwinds products

i would like to see a 64 bit version of the solarwinds products, This would allow the product to access and use more addressable memory within

the Servers i install the products on.

Parents Comment
  • The only tangible benefit to 64bit is that a single process can address more than 2GB of ram. It doesn't improve performance in any way. Not unless you have a process that's memory constrained. As you can see below, no single process comes anywhere close to consuming that amount of memory.

    Process Memory.png

Children
  • Oh no, I meant the Linux part, not the 64-bit part. And that's cause I'm a rabid anti-windows bigot.

  • I consistently see Info Service v3 using up to 1.5Gb of memory so I wouldn't say it doesn't come close.

  • 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.