Very large Drupal Website Having Troubles

what i suggest is:
disable database log and enable syslog(if u need it)
try something like memcache
if the search is used alot try sphinx
dont know about your errors at boost and T.VTN
maybe u need better server

I am quite frustrated, especially when GoDaddy says that Drupal cannot handle such a large website, but I think to myself that drupal.org is pretty darn big, so why the heck not?

Well I don't know how your traffic compares to drupal.org, but drupal.org doesn't run on the equivalent of a modern low end laptop. d.o uses multiple web servers, a couple of large DB servers, a reverse proxy etc and a lot of custom DB tuning.

Without knowing what your traffic levels are (especially authenticated traffic), it may be that you have enough hardware. But I doubt it.

I don't know what exactly is in the node revisions table - is that where the data is stored or is the data in the node table? I don't need to maintain the old revisions of the data, I just need the current version of it. Does node revisions have multiple copies of the node data in old revisions? Can I dump it safely?

No. The node_revisions table contains the nodes content etc. You only have 2 more revision records than node records, so there isn't any room to delete stuff there.

When I remove a module, the tables seem to stay there. Are there any tables that I can safely discard given the modules I am running? See database snapshot: http://openjurist.org/DRUPAL-DATABASE-HELP.png

Have you uninstalled the modules after disabling them? Properly written modules have an uninstall routine to remove their tables.

Most importantly you should install a bytecode cache. Either eaccelerator or APC. Both work well. Then you should have a look at why mysql crashes. What do the log files of mysql tell you? Do MySQL tables get corrupt? Which Storage Engine do you use (MyISAM or InnoDB)? Have you enabled the slow query log? Do you have RAM or CPU problems? Is your mysql tuned to the number of visitors on that page? Is the query cache enabled? Do you have enough processes, is your wait time too long? Perhaps you have filesystem problems? There is not enough information in your post, honestly.

I had "forgot" to set a cron job and my watchdog table grew to over 4GB and kept crashing. It got so bad that my shared hosting provider had to shut my site down due to it was causing problems to other sites. Watchdog was the problem. I emptied it and it was smooth sailing from there. I lost about $2K in sales while my site was down. :(

Sorry to hear about your problems.

I am not sure whether you mean just the database/content size is large or whether the traffic volume is sizeable too.

Anyhow, either way here is what you need to do for sure:
1) Enable PHP APC
2) 1GB Ram is quite low, make it at least 4 GB
3) Change all database tables to InnoDB
4) Index all database columns where you have major join queries

For the long term, get a better server:
www.rackspace.com provides some of the best servers that is scalable with perfect support.

Look into having a second server that servers as a pure database server.

You can check out my case study http://drupal.org/node/422260 for more info on how Drupal can be further optimized.

Maybe it's just me, but imo "very large website" and "godaddy" just don't belong together. =/

Pfft, GoDaddy is clueless. Is that -really- a dedicated server with a celeron processor?

First I would go through all the MySQL and PHP configs and make sure they are streamlined in accordance with those echoed by 2bits and other such dev shops. Secondly (immediately) I would see if they can add 2+ GB to the server.

Node revisions table is the table that holds the body/teaser content for a node. The node table is the 'master' table of nodes, and has no content. Don't dump either.

I've heard of issues of using Plesk, especially when it comes to upgrading PHP, MySQL and other server level applications.

You may want to look into Squid and eAccelerator.

Some modules don't come with uninstall routines (this should be a mandate...) to remove their database tables or variables data.

What we've seen is that MySQL chokes on cache data. Try having it empty cache every hour. Cache should never be GBs worth of data... no wonder MySQL is dying.

One question...

"646,262 records in the node table and 152 megabytes,
646,264 records in the node_revisions table at 8.7 gigabytes"

What kind of site is this?

Is your mysql instance hosted on the dedicated server, or does the dedicated server only serve httpd traffic? I think you may have your memory limit on php set a little too high (128mb is a bit excessive, you could probably get away with much less). As noted, if your mysql instance is on your dedicated server, you're way under spec. What's probably happening is your db is querying for data, the db needs to join a few tables, hits swap, and then commits suicide.

Also, keep in mind that innodb requires more resources than myisam. Until you convert over to a bigger, better machine, if you are in fact running mysql with big tables like yours on a server with only 1gb of ram, you should probably keep your tables as myisam. You could end up increasing your crashing by converting without the proper hardware in place.