Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
VFP app with SQL Server works faster after reboot
Message
From
14/03/2024 11:55:58
 
General information
Forum:
Visual FoxPro
Category:
Troubleshooting
Miscellaneous
Thread ID:
01687680
Message ID:
01687722
Views:
40
>>>>If a Windows computer (server or workstation) slows down to the point of unusability, it's almost always because the disk subsystem is overloaded. Some major causes of this:
>>>>- Unknown or unexpected heavy disk I/O such as backups running during business hours, other apps running on the server etc.
>>>>- Insufficient free RAM memory, forcing memory to be paged to disk
>>>>- Low free disk space (under 5%) causing file fragmentation, especially with mechanical HDDs
>>>>
>>>>I would do these checks, in this order, while the server is functional:
>>>>1. Check free space on server disks using File Explorer
>>>>2. Use Task Manager to check RAM memory usage. You can also check if anything is pinning the CPUs but on modern systems that's unlikely unless it's a VM that's underprovisioned with vCPUs
>>>>3. On the Task Manager Performance tab click on "Open Resource Monitor" at the bottom. When RM is open, go to the Disk tab. Scroll to the bottom and expand the "Storage" section if needed, then for the logical disks review the Disk Queue Length and Active Time % columns:
>>>>- on a system with a strong enough disk subsystem, Disk Queue Length should almost always be between 0 and 1, and Active Time under 10%.
>>>>- a heavily loaded but acceptable system will have 100% active time and may have DQL hovering around 3 - 5. Anything higher is overloaded
>>>>- I have seen grossly overloaded systems with DQL consistently over 15 and peaking over 200
>>>>- if high DQL is found, look at the Disk Activity section in RM (e.g. Total B/sec) or go to the Processes tab in Task Manager and sort them highest to lowest by Disk utilization to find the culprit(s)
>>>>
>>>>Since its early days SQL Server has been marketed as "self-tuning" and not requiring a DBA for many common use cases. Yes, by default it will use as much RAM as it can get hold of, but modern versions are pretty good about returning RAM to Windows if the OS is busy servicing other apps or doing other things.
>>>>
>>>>A while back I was working with an HP server, 8GB RAM, 2x 1TB mechanical HDD in RAID1. It had a SQL Server 2012 Standard instance and also ran a couple of RDS sessions with a VFP fat client app. I don't recall seeing that server go over 7 GB RAM in use and it never needed any SQL tuning. Client app performance was good even over a slow DSL remote connection.
>>>>
>>>>More recently I set up a Hyper-V host with 4x 4TB mechanical HDDs in RAID10 on a high-end caching RAID controller. The largest VM is provisioned with 48GB RAM and 10 vCPUs. It has an instance of SQL Server 2019 and supports a parametric CAD app with ~10GB of databases. Performance is excellent and I have never seen that VM report over 10GB total RAM usage (no custom tuning). The client is happy to let that VM use the rest as disk cache, and if SQL Server decides it temporarily wants more for some inscrutable purposes, it's available for that, too.
>>>>
>>>>So, a SQL Server Standard instance running on a server with 8 GB RAM can be OK as long as it's not overwhelmed by lots of other apps or services. If it's slow, do some basic research and find the bottleneck(s).
>>>
>>>Thank you very much for a detailed message. I will read it carefully tomorrow (too tired right now to focus). And maybe will send some of the items you suggest to the customer IT.
>>
>>Al is on the mark as usual - but consider time and cost.
>>
>>Actually I'd ask the customer if the machine accepts ANY further RAM.
>>Quadrupling the physical memory should cost less than the time
>>spent searching for different software settings - and if the machine
>>only has 8GB physical allowed, CPU, RAM and board are past their prime.
>>
>>Searchin for the culprit after having ample RAM is usually easier as well.
>>
>>regards
>>thomas
>
>I thought about asking the customer to look for more memory on the PC (hosting the SQL Server). But I decided not to do it. They - the customer company - is a large organization and should have a DBA who should (or maybe will) look into improving the SQL Server operation. So far, with the help of Borislav, Dragan, and others, I pointed to the IT "where" may lie the problem. The rest is up to them.

Something off in my visualization - if it is a large org, they should have more expirience with their IT, HW and SW.

A physical server with 8GB sounds weird for a large org - why don't they virtualize it with other machines ?
Playing with more cores or more RAM gets easy that way.
If it really is a separate physical box, anything not allowing upgrade is a dud.
Could be they bought a tiny board with 2 slots and filled with 2x 4GB,
but even more than 12y ago they had DDR3 allowing 2x 8GB.
If they were smart enough to buy a something with 4 RAM slots,
even old DDR3 supports 32GB - which should be most of the old Cores,
even some earlier than the bad hot beast midst of last decade,
the i7 4790K, as I have one of those with 32 GB as my backup in the cellar,
just in case my newer machines barf at the same time (virus or flash...)
From specs it should reach between 1/2 and 3/4 of my current HW,
but not turned on in the last 4y more than a dozen times.

In your case probably DDR4, which supports up to 32GB per slot -
64 GB of RAM in 2 slot laptops of prev generations possible,
allowing to run quite a few VM plus a small RAM-disk
when you have a compiler creating .obj files to link into dll, exe or something else -
or run some back end SQL at high speed for < 3$ HW cost per GB of RAM.

Total new box is probably not economical due to your lower electricity cost per KWh,
but getting a handme-down less than 10y old from any office getting new stuff
-and adding 75$ of RAM if slots are all full (as error correcting RAM not supported)
should give you nice ROI.

If your MS SQL server is the only MS SQL server they use (and they are a significant client),
perhaps offering to use their usual SQL server might be wise, as their DBA has to deal with it,
and on your side the effort should be billable while you get experience with another backend
plus you are then outside the "only MS products" fold.

You have different ways to introduce the topic - but not *mentioning* HW in my book is wrong.
(I know that my approach is not considered polite or nice, but it evens out in the long run)

my 0.00022 €
thomas
Previous
Reply
Map
View

Click here to load this message in the networking platform