> Seems like a stretch between the hardware for stating a true difference. > scsi / sata boot / non boot. > > How big in gigs is the db? > > Is the processing done on the server or is it just pushing the data to be > processed in VFP and then sent back ? > >
I am simply using the equipment I have on hand in their current configurations at this point. I want to get a baseline before dumping any moe cash into the machinery, especially if performance is decent as things are now. But, if more RAM, and SCSI HDD units are needed, then so be it. The current DoNotCall database in PostgreSQL is just over 2.5Gb, but that is only using the Area Codes my clients need me to process. If I pulled in all Area Codes it would be tremendously larger. I pull the CSV file for all Area Codes each month, so if I was curious about how it would affect things I could import the files (one file per Area Code, amazing...). I am using the Dell Server to house the PostgreSQL database on a 73Gb SCSI HDD (7,200 RPM, Ultra-Wide SCSI, Adaptec 32bit PCI adapter). I do the processing using an AMD 3.0Ghz CPU with 2Gb RAM. The network is an HP 100vg backbone (no collisions, never drops below 98mps net throughput no matter how heavily the LAN is loaded, so the LAN never impedes my processing in practical terms). In order to speed up my processing with the VFP Remote View on the PostgreSQL database I use my RECCOUNT() trick to blast the PostgreSQL records into the workstation. Any slected tables for client updates are written to VFP tables onto the ftp Server HDD, and Zipped using ZipGenius via CLI. The ftp Server HDD is a simple 300Gb IDE unit. It all moves along pretty fast. I have not done any serious performance measurements on different parts of the process yet, but the part that takes the longest seems to be importing all the .csv records into the PostgreSQL database. Then again, the .csv files are also coming from the ftp Server's 300Gb IDE HDD, and that ftp Server is pretty busy at times with folks hitting it from all over the planet (some are just chinese and korean attacks). Gil > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Stephen Russell > Sent: Tuesday, April 01, 2008 1:44 PM > To: [EMAIL PROTECTED] > Subject: Re: [NF] RE: Microsoft New SQL OS >>> PostgreSQL info > > > On Tue, Apr 1, 2008 at 12:04 PM, Gil Hale <[EMAIL PROTECTED]> wrote: > > > I forgot to advise the ProFox group of the apparent latent impact on my > > Dell > > sc430 Server when I hammered it so heavily processing a huge number of > > Federal Do Not Call records the other week. The sc430 runs Windows 2003 > > Server, and had 1Gb DDR2 ECC RAM (512mg x 2, from Dell). I noticed the > > morning after running the VFP processes used to update dbf tables for > > distribution to clients, drawing the client record sets from the > > PostgreSQL > > database, my scheduled morning VFP TranslationEngine app was running dog > > slow. I checked the sc430 Server and found it had not fully > released the > > RAM it ate up running the PostgreSQL processes - likely because I still > > had > > that app (and PostgreSQL tables) open so I could tweak it "later on". > > Upon > > closing the DoNotCall project the sc430 Server RAM climbed back to where > > it > > normally runs. > > > > So, in an effort to prevent poor performance issues, and in keeping with > > all > > I have read about PostgreSQL performance and how to enhance it, > I ordered > > 2 > > 1Gb DDR2 ECC RAM chips (installed them this afternoon). I will be > > processing the DoNotCall updates again next week, using the VFP project > > that > > interfaces with the PostgreSQL database. Assuming anyone cares to know > > what > > happens with the performance with the additional RAM I will report the > > results, even if somewhat anecdotal. The sc430 can handle 4Gb > RAM, but I > > wanted to see how this does first. After that little > experiment I plan to > > migrate the PostgreSQL database from the Windows 2003 Server to a Ubuntu > > Linux v-7.10 Server with a "paltry" 1.5Gb RAM in it, just to see how it > > performs in comparison. Both Servers have an Intel P4 2.8Ghz Dual-Core > > CPU, > > the Dell has 3Gb RAM and uses a non-boot SCSI HDD for the PG > database, the > > Compaq has 1.5Gb RAM, and uses its boot SATA HDD for its PG database. > > Both > > Servers can be pumped to 4Gb RAM if need be. Let the games begin! > > heh-heh... This is too much fun. > > > ---------------------------------------------------------- > > Seems like a stretch between the hardware for stating a true difference. > scsi / sata boot / non boot. > > How big in gigs is the db? > > Is the processing done on the server or is it just pushing the data to be > processed in VFP and then sent back ? > > > > > > > > > Gil > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] Behalf Of Gil Hale > > > Sent: Tuesday, April 01, 2008 11:50 AM > > > To: [EMAIL PROTECTED] > > > Subject: [NF] RE: Microsoft New SQL OS > > > > > > > > > Brat! I was about to cut from PostgreSQL to the new SQL OS because I > > > thought M$ finally did something right. Grrr... > > > > > > Gil > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] Behalf Of Alan Bourke > > > > Sent: Tuesday, April 01, 2008 6:33 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: Microsoft New SQL OS > > > > > > > > > > > > 2 things! > > > > > > > > April Fool, and XP SP2 is as bug free as any OS I've used. > > > > > > > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
