Open for Voting
over 2 years 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.

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

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

  • So Just theorizing here, but have ran into countless issues that seem to come back to the lack of 64-bit processing in Solarwinds/Orion. The SDK API for example does not allow the transfer of a 4-byte AS that greater than ‭2,147,483,647‬. And results in either a negative number, or if you perform math against a string representation, the conversion to an integer results in an elusive error: The conversion of the nvarchar value '4227927296' overflowed an int column.

    Others have argued and requested 64-bit under the suspicion that running in 32-bit translated mode (using WOW64) is causing performance issues. Reasons stated include

    • Inability to maximize use of available RAM
    • General performance degradation in larger networks.
    • Warning Messages calling out supportability during install when deploying on 64-bit versions of SQL server

    In multiple forum posts, engineering defends their reason for not porting to 64-bit as not required and complicated. Under the following reasons:

    • Orion is not one process but many, which holistically can utilize more than 2 GB per process..
    • Where Needed WOW64 (Windows on Windows emulating a 32-bit or 16-bit environment) allows for the ability to run the 32-bit Orion Process on Windows.
    • 64-bit actually increases overhead (which while true is irrelevant) and can make the system slower (which it rarely does).
      • The reality is while overhead can and will increase in areas where its needed, the structure of the representation for an individual "word" length can still accommodate 32-bit (integer/double), 16-bit (short/float), and 8-bit (byte/char).
      • The only place where overhead is increased uncontrollably is in the pointer (memory reference) mechanism in the controlling constructs of code, which accounts for a very small % of the footprint of most systems as a majority of the data in memory is not execution structures, but storage structures. They persist for long periods of time and are static (in place) a majority of the time.
    • This inefficiency significantly outweighed by the following performance advantages:
    • The ability to keep larger chunks of the swap pages in RAM and not having to go to disk in larger datasets results in less page misses and provides decreased latency in user requests for data.
    • This also means that calls that are cached by the local SQL API instances within Win32 API, MFC, RPC, and Dot.NET should perform better (pending the code is written to take advantage of these functions) as they have to make fewer calls to the SQL server during the transfer of a dataset to local memory for processing.
    • The computational time for large numbers (which do not fit into a 32-bit structure) is decreased significantly (16 fold in some tests) as the operating system's execution scheduler and the processors ability to predict which order to execute instructions in the pipeline becomes much simpler.
    • What is surprising is that Solarwinds/Orion (a networking product in nature) doesn't understand is that a large swath of the SNMP MIB that they are gathering information from is already 64-bit in nature. Their product will GREATLY improve in performance if it is executing 64-bit native. A lot of the data is stored (incorrectly) in the database as int (IP Addresses, Autonomous Systems) and a lot of times duplicated with a nvarchar representation of the tuples or GUID, which is stored as a signed 32-bit number. This results in overflow (either as an error or the resultant number being negative) issues when you exceed 2^31, that they are most likely resolving with additional processing (overhead)

    This is not a knock on the Solarwinds/Orion Team. The company I work for has been loyal customers since 2005. I personally have used the product since 2000ish.. maybe as early as the late 90s. They product they have created and maintain for the cost of ownership is extremely powerful. However, I like many others would like to see resources dedicated to the future instead of arguing to stay in the past. I completely understand that are large portions of the system that complicate the ability to transition to 64-bit. But in the end, I like many others think the product will scale and perform much better.

    But I do think honesty from the Solarwinds engineers (or education where misunderstanding the myth of 64-bit performance) will go a long way towards the continued support of the product by its userbase. There needs to be the announcement of an initiative to get to 64-bit and there needs to be adequate emphasis and communication to the userbase on how and why it will take whatever time it takes to get there.


  • solarwindsmemory.PNG

    Which I could vote more than once....and our deployment isn't completed.