Neowin on SATA instead of SCSI


Could SATA be the problem on the new server?  

38 members have voted

  1. 1. Could SATA be the problem on the new server?

    • 1. Yes, SATA like EIDE generates too much work for the CPU to handle many small requests.
      11
    • 2. No, SATA does not have the problems associated with EIDE
      1
    • 3. No, it is a DDOS attack
      2
    • 4. No, it is too many users that is causing the problem
      1
    • 5. No, mySQL is not configured properly
      2
    • 6. No, it is some other problem
      5
    • 7. I don't know the difference between EIDE, SATA and SCSI
      3
    • 8. I don't care, I just want it fixed
      13


Recommended Posts

SCSI off-loads the CPU and is particularly proficient when processing multiple requests for data simultaneous (or as close as simultaneously as possible).

EIDE (and presumably SATA) generates CPU interrupts to process data transfers. It's fine when you have a single user but under heavy multi-user stress it generates a lot of extra work for the CPU.

If the new server does indeed use SATA to replace the SCSI used in the old server then I think this could be part of the problem.

I hope this doesn't double post the thread. Slooow.

Link to comment
Share on other sites

lol...and you put this in the wrong forum...:s

I figured the people who frequented the hardware hangout would have some ideas as to whether it was hardware related or not. But I guess Site and Forum issues would have been better.

Link to comment
Share on other sites

i read in another thread recently that it only occurred during the daily backups.

just don't come during the daily backups :D

They must backup A LOT. Today it was down from 6-8pm EST or thereabout. The other day it was down from midnight to 1AM EST. By down I mean that there were NO new posts during that period. That doesn't just mean the occasional mySQL error or "Too many connections" messages.

Link to comment
Share on other sites

I know RHEL had a problem in the kernel with disk I/O. Had this problem on one of tim's servers, finally got it fixed. Might want to look into that if you havn't.

Link to comment
Share on other sites

The problem is the daily backup process. That's the *only* cause of the problems. When it's not running, things go smoothly. The slowdowns have nothing to do with SATA vs SCSI performance because the last server was running on EIDE drives anyways...

Link to comment
Share on other sites

not according to this:

If you are reading this then your DNS has updated to our new server. These are the specs:

Dual 2.8Ghz Intel Xeon Processors - from Dual 2.4Ghz Intel Xeon Processors

3GB ECC Registered Ram - from 2GB ECC Registered Ram

Dual 80GB SATA HDD - from Dual 75GB SCSI-3 HDD

2000 GB Bandwidth - from 1200GB Bandwidth

Edited by xStainDx
Link to comment
Share on other sites

This backup issue was never an issue with the last server... whats probably happening.. which i'm possibly wrong is the backup is taking all the disk I/O and thus making it seem like the database is missing and cannot connect.

But.. I leave the server up to Redmak, and Neobond. I'm just a member. :p

Link to comment
Share on other sites

This isn't a matter of opinion, there is a problem, it's either this or either that, not 'what do you, the user that is as uninformed as the poll creator, think is the problem?'

Link to comment
Share on other sites

This backup issue was never an issue with the last server... whats probably happening.. which i'm possibly wrong is the backup is taking all the disk I/O and thus making it seem like the database is missing and cannot connect.

But.. I leave the server up to Redmak, and Neobond. I'm just a member. :p

Because backups weren't performed the same way with ev1. ThePlanet has a Veritas backup system and a completely different backup script. I know it's being worked on as we speak (and ThePlanet's techs are usually pretty diligent about this sort of thing).

And the problem isn't how long the process runs, so much as how it freezes up the server and sends processes into an I/O wait state.

Link to comment
Share on other sites

Well what ever the problem hope it gets fixed soon. I signed on to the net around 5pm MST could not get to Neowin, about 15 mins later I got to the front page, but took forver to load the forum, never was able to view any posts.

Came back around 8pm MST Still not able to get to neowin, checked every 15 mins, some times I could get here and view a few posts but would soon get 404, SQL, or another error that says something like "Sorry we had a problem with the database, try reloading". Since about a hour, 2 hours ago it's been working fine.

Link to comment
Share on other sites

We had this problem with our server, everytime we backed up to an extrenal server, in oour network. The server went as slow as ****, it was unusable

btw, im in the planet too

Link to comment
Share on other sites

We had this problem with our server, everytime we backed up to an extrenal server, in oour network. The server went as slow as ****, it was unusable

btw, im in the planet too

did they get it fixed?

Link to comment
Share on other sites

We had this problem with our server, everytime we backed up to an extrenal server, in oour network. The server went as slow as ****, it was unusable

btw, im in the planet too

Lost in space I guess... :whistle:

Link to comment
Share on other sites

No, we had to partition our hdd, and backup to that. That worked

Did you then from the second partition move it to an external backup, or do you just keep all the backups on the second partition?

Link to comment
Share on other sites

The backup is causing our problems, and yes backup does take hours. theplanet are aware of our issue and have informed us they are looking into it.

when backup isn't enabled we have sub 1 server loads (like now at the time of this post)

[ Script Execution time: 0.2401 ] [ 13 queries used ] [ GZIP Enabled ] [ Server Load: 0.26 ]

  • Like 1
Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.