Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
SQL Server - High Performance Disk Subsystem
Message
From
23/03/2008 16:19:13
 
 
To
23/03/2008 11:19:06
General information
Forum:
Visual FoxPro
Category:
Client/server
Environment versions
Visual FoxPro:
VFP 9 SP1
OS:
Windows Server 2003
Miscellaneous
Thread ID:
01304529
Message ID:
01304760
Views:
28
Hi Thomas,

>>Being a big believer in Pareto's Law, I have to ask myself what do we really need to fix the problems? That's why I'm trying to get some feedback here < g >
>
>Having externals tweak config is expensive as well - just throwing HW at the problem is actually a pretty good strategy<bg>.

Fully agreed! Hardware is cheap, can be more cost-effective than having a bunch of expensive people standing around scratching their heads < g >

>>Re: the partition - we were specifically told by the VAR to set up the disks that way :-(
>
>At least they are out of business now!

We were told by our CURRENT VAR, not the one that went out of business :-(

>
>>>>- 4 disks in RAID10 for Windows and the swap file ( C: )
>>>This causes one highly raised eyebrow - what is swapped here to need that setup ? Especially Raid10 for a swap file ?
>>>Better image your boot partition and Raid0 the swap file, if necessary at all
>>
>>The swap file will get hammered in low memory conditions, so yes, a RAID0 at least will probably help. If the OS (without swap file) is put on yet another volume, for redundancy that would need to be RAID1 anyways. Add 2 more drives for RAID0 on the swap file, and you're up to 4 drives. That may be why RAID10 is recommended here.
>
>Still doesn't fly with me, as you can prepare the installation to use other disks for swap. These other disks will be used if the room on the first disk is not enough or the first swap disk has problems. Analogous thinking from client OS behaviour, doubt if server behaves differently.

Not sure I follow you here - can you expand on this?

>>The Xeons seem to be Prescott/NetBurst: "PROCESSOR..., 80546K, 3.0G, 2M, XEON IRWINDALE..., 800, R0". So, lower performance than Core2, but I don't recall ever seeing the server even close to being CPU-bound. Especially since SBO is not true client-server, so a lot of the query grunt work is being done on the workstations. Have you seen any numbers on how these CPUs perform 64-bit vs. 32-bit in W2K3?
>
>If it is REALLY Netburst, shoot the person recommending such a server. Yes, FSB will eat into scalability much earlier, as the CPU caches are smaller (might become even more pressing in 64Bit). But ALL Opteron based solutions give much better scalability than Netburst servers. Try earlier Tweakers or Anand for comparison. IF this is just a bogus arguement to get a Core-based server smile and agree.

The server was spec'd/bought in October 2006. Core2 Xeons were exotic/expensive at that time, Opterons not much better. We ordered what was cost-effective, and again, it was a *lot* more CPU than the (then-) recommended minimum.

>Did he try for perfect storms with the SBO app running on different WS at the same time ? 30MBit/s might create the backlog, if a sizable amount of data is "planned" to travel the down wire. Dunno if file cache trashing might become pert of the oicture. Try GB net at two WS.

We saw the high spike in ADQL even with just one w/s running an intense report/query. No doubt more w/s would have been worse. At that point the VAR guru had seen "all he needed to see".

Again, thanks for your advice. Cheers.
Regards. Al

"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov

Neither a despot, nor a doormat, be

Every app wants to be a database app when it grows up
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform