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.

Find more posts tagged with

prodfr

Status: None

Comments

tedwards

As all modern OS's run 64-bit, and very few are still running 32-bit, it doesn't make since not to make the SolarWinds product line 64-bit to be able to take full advantage of the capabilities available on 64-bit OS's

Sohail.Bhamani

There is very little 32bit left in the Orion Core. I spoke with one of the developers recently and he mentioned they are almost done with the removal of old VB6 code. They are moving to completely .net 64 bit. He also mentioned that the job engine and module engines along with many other needed processes are already running in 64bit. Just an FYI. I will still vote on this, but this is definitely all continually in progress according to SW dev.

amstephen87

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

adatole

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

uidzer0

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

orionshark

Try this tip!

Tip: How to Improve Orion Performance by Splitting the Module Engine to Separate Processes

cstephan

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.

Thanks!

ecklerwr1

This would be a good thing...

austringer

It would also be very beneficial to be able to use for e.g. 64bit Oracle ODP drivers to monitor Oracle RDBMS. We have systems that cannot use 32bit drivers as the appstack vendors prohibit modifying their environment and they only support 64bit.