Custom properties numeric limitation

Question

When I create a custom property, set the format to Integer Number, tick the Restrict values checkbox and start entering integer values, it appears that these values are limited to 32-bit signed integer values.  Normally this would be sufficient, but I have one special case situation in which I need to enter some values that exceed the range of 32-bit signed integers.  Has anyone else had this issue or know of a quick work-around?

cstephan · Answer

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!

ekis · Answer

Yeah it looks that that is indeed the case.

Also, in the process of creating a custom property, there is an option for the integer data type but none for a bigint data type.

Try submitting a feature request for SolarWinds to allow bigint data type for custom properties either via a phone call or ticket to SolarWinds Support.

Alternatively, you can post the feature request here in Thwack.

Just my 2 cents.