Man I cant wait to see BF2s.com running on this beast!
I've got the stats updater working, and the basic stats page working on it with the new code base -- sweet jesus it's fast
Awesome! I'm sure you have folks helping you out, but if you need any Linux help, let me know. I've been doing Linux/Unix admin for the past 7 years. Just out of curiosity, what sorts of things are you doing to make things better? Also, are you doing all this stuff with PHP4 or PHP5 and are you using an object oriented model or straight procedural? I'm trying to make the transition to PHP5 objects, but it's sort of difficult since my coding experience has been mostly procedural...I'm an admin by trade, wannabe coder occasionally.
Last edited by Rugmonster (2006-03-01 20:50:03)
Well, it's all the latest code bases -- so PHP5, MySQL5, Lighttpd.
The reason for not having switched over is that the previous site was a PHP4 OO -- meaning, just dirty procedures wrapped in a sorta OO approach.
As such, I'm essentially recoding the entire site. I restructured the database, recoded the updater, and have about half the stats page done (award requirement updates are going to be a REAL bitch to update...). That leaves...the rest of the site to port over, plus all the extra features that I am now going to be able to build (which you can find hints scattered around here.)
The reason for not having switched over is that the previous site was a PHP4 OO -- meaning, just dirty procedures wrapped in a sorta OO approach.
As such, I'm essentially recoding the entire site. I restructured the database, recoded the updater, and have about half the stats page done (award requirement updates are going to be a REAL bitch to update...). That leaves...the rest of the site to port over, plus all the extra features that I am now going to be able to build (which you can find hints scattered around here.)
SWEET JESUS MAN!!!!!!!!!!!!!!!!!!!! your my hero chuy,,,, me and the guys at the restaurant who play would like to say that anytime your in the philly/wilmington area, stop in,,, dinner is on us,,,,,buckleys tavern , centreville delaware
i know ive said it once but i got to say it again,,,,,TYVM,,,, THIS IS BEST BF2 SITE ANYWHERE HANDS DOWN
i know ive said it once but i got to say it again,,,,,TYVM,,,, THIS IS BEST BF2 SITE ANYWHERE HANDS DOWN
i wont get into a flame war. i wont protest to be some IT whiz
one question though how the hell do u keep those 2 optys cool with passive cooling like that!
the optys do run a bit cool though. my 170 dual core only peaks at 39c at full load with both instances of prime running at 2.5 ghz
nice chip
stock cooling!
although my crib is pretty chilly..keep the temp at 72
which really is like 69 ambient
i need to use a diode though..it was easy back in the old athlon days...circa 01.
now its to much of a pain and i dont have teh time.
back to my beers
one question though how the hell do u keep those 2 optys cool with passive cooling like that!
the optys do run a bit cool though. my 170 dual core only peaks at 39c at full load with both instances of prime running at 2.5 ghz
nice chip
stock cooling!
although my crib is pretty chilly..keep the temp at 72
which really is like 69 ambient
i need to use a diode though..it was easy back in the old athlon days...circa 01.
now its to much of a pain and i dont have teh time.
back to my beers
Last edited by beerface702 (2006-03-02 01:52:22)
Chuy, I recently moved my LUG's site to PHP5 and that alone sped things up considerably. Each page was taking on average .8 secs to render and went down to .62 secs. No changes in code or optimization on the DB. I was shocked. Hopefully, you get similar results.
Beerface702, sorry for the harsh attitude before.
It isn't so much passive cooling because there are a row of high speed fans that sit just before the memory/cpu sets. Basically, they move so much air past the heatsinks and memory, that it keeps them plenty cool. Due to the size restrictions when using a 1U case like that, you see those little loud fans all over the place. I am surprised to see only five centrally located. Typically, you'll have two of those on the front side of the CPU's heatsink (at least on most P4 Xeon servers). Those things are super loud because they're spinning so much. We've got 8 full racks at work and you pretty much have to yell to talk if the person is more than 6 feet away.
Beerface702, sorry for the harsh attitude before.
It isn't so much passive cooling because there are a row of high speed fans that sit just before the memory/cpu sets. Basically, they move so much air past the heatsinks and memory, that it keeps them plenty cool. Due to the size restrictions when using a 1U case like that, you see those little loud fans all over the place. I am surprised to see only five centrally located. Typically, you'll have two of those on the front side of the CPU's heatsink (at least on most P4 Xeon servers). Those things are super loud because they're spinning so much. We've got 8 full racks at work and you pretty much have to yell to talk if the person is more than 6 feet away.
Last edited by Rugmonster (2006-03-02 05:20:36)
Not passive There's about 12 small, very fast, very loud 40mm fans on that biotch. It's like turning on a Hair dryer. Loud as all hell.beerface702 wrote:
one question though how the hell do u keep those 2 optys cool with passive cooling like that!
Oh, I also installed APC (a caching mechansim) that stores the PHP files in a compiled state --which helps considering the key file (the one with all the award descriptions and reqs) is about 65k !Rugmonster wrote:
Chuy, I recently moved my LUG's site to PHP5 and that alone sped things up considerably. Each page was taking on average .8 secs to render and went down to .62 secs. No changes in code or optimization on the DB. I was shocked. Hopefully, you get similar results.
says in his best Napoleon Dynamite voice, "Lucky"
I registered just to point out that this is completely incorrect.AD_Kensan wrote:
Nobody in their right mind would put any flavor of Windows on such a Server. Even Windows 2003 Server has a max of 4GB Ram that it supports (it would not recognize more than 4 Gigs).
http://www.activewin.com/reviews/software/operating-sys/win2003serv/pricing.shtml
Eh, it's no Linux, but at least it isn't windowsAD_Kensan wrote:
Chuy said that he will put FreeBSD on it which makes me happy. Go *nix!
Also - whoever said flat out that Intel was "better for servers" - punch yourself in the balls. Thats a ridiculious generalization, and is dependent on what the server is <I>DOING</I>.
There are several SATA drives that have beaten SCSI drives in non-sequential reads (read: normal use). It has more to do with the logic in the controller than the drive. Think NCQ here, etc. There's lots of features of SATA controllers that make them fast. Get it out of your head that RPM speed is the sole limiting factor of a disks performance.Nabraham wrote:
To the person who said the SATA drive is a fast if not faster than a SCSI drive can you show me a SATA drive faster than 15k rpm?? Ive yet to see one. In fact the fastest ones ive seen are the 10k raptors.
As a general rule - yes, SCSI is still faster, but there are cases in which SATA2 (300mb/s) has/will outperform 15k SCSI @ U320.
FYI - you can address a shitload more than 64GB of ram with a 64bit integer, signed or unisgned.chuyskywalker wrote:
As for ram -- soooo much misinformation. Any 32bit os will ONLY support 4gb of ram, max. PERIOD. After that, it's all make believe ram support -- it's not really going to be great.
Any 64bit os can fully support UP TO 64GB of ram. Therefore any of the *nix builds for x86_64 will work, and also WinXP64 works great.
http://en.wikipedia.org/wiki/Integer_(computer_science)
64 bit
doubleword, longword, quadword
Signed: −9,223,372,036,854,775,808 to +9,223,372,036,854,775,807
Unsigned: 0 to +18,446,744,073,709,551,615
C long int (on 64-bit machines), C99 long long int (minimum), Java long
Ok, first off, I can't believe I'm posting again. Just so much inaccuracy in this thread.sixshot wrote:
I personally like Gentoo for flexibility. Fedora is bigger (in name?) but I personally do not like having to sort through 4 CDs of RPM packages if I wanted something very minimal and lean. Debian and Gentoo should give you the best in flexibility with minimal disk consumption. But then it's already too late to switch over. Oh well. I hope that server blazes through everything you throw at it.
Inquiry: Are you using the binary RPMs or the SRPMs? I'm thinking that it might be a little better building the Fedora system from SRPMs to possibly better optimize the binaries for the platform it's installed on.
1.) Quit whining about having options. If you don't want the package, don't install it. Plain and simple. They don't send you four CD's because they expect you to install it all, jesus.
2.) No, it really wouldn't make much of a difference to compile it from SRPM. He'll be installing the x86_64 version, thats highly optimized for exactly the CPU's that are sitting in his hardware.
There's a few problems with this logic. His post is correct.chuyskywalker wrote:
MySQL does this for certain kinds of database engines (namely, MyISAM tables.) However, I am mostly using InnoDB tables wherein the index and data reside in a singular large access file. Regardless, the amount of ram I am throwing at mysql will make disk access speeds pointless -- and I hhighly doubt the index will outgrow the capacity it's allocated anytime soon.
Consider disk seek time. The drive will have to swap back and forth from accessing the index, to data files, to index, to data files, etc. Its *VERY* common practice to split datafiles and tlogs on two disks. I also throw my temp on another set of raid 0+1 disks as well (for my apps w/ heavy (#|##) table usage).
My recommendation to you would be to setup a ramdisk (just append it to your kernel line, mk2fs it, etc, you can find guides on the web) and put your mysql database and indexes there. Not like you don't have the space. Then just mysqldump everything to disk once a day (once an hour? who cares, just regularly). Your access times will go from milliseconds to NANOseconds (factor of 1000 here). The performance isn't even comparable between disk and ram (as I'm sure you know). You've got the ram, USE IT!!!!
Also - you may want to take a look at memcached, especially with as much ram as you have. It's limited to 2gb per instance, but you can just run as many instances as you need.
EDIT: Just read you opted for APC, whatever works, I'm not picky
Last edited by jon3k (2006-05-09 15:42:20)
Just wondering but did you keep the 7800GT in there? Sorry for reviving the topic but I just had to know.
No, the 7800 is my main machines card. lol, a server wtih a 7800 would be silly.
As for the MySQL stuff. I generally have found mysql quite adequate when I give it several gigs of ram for it's various buffer pools. Also, several of the table are MEMORY type tables which does the same thing as making a ram disk. (with backups, of course.)
I tried for doing a ramdisk type thing, it was just too much of a pain to do (especially the backing up part -- even a hot dump once a day would make the website cry during the process). Mainly, I ran out of time to set it up and sufficiently test it before moving to the new server.
I did look into replication as a good way of doing the DB back up, but again, ran outta time. Additionally, most tutorials and guides and such are geared towards teaching you about server to server replication, whereing I was thinking about running client->client replication on the same machine.
Finally (promise) I'll probably install memcache at some point. I wanted APC for the precompiling and code caching it does -- as I've discovered that it's shared memory space is HIGHLY unreliable. (Maybe just my setup, but I can NOT get constant results. I store something, the refresh a page that "pulls" that something -- it's a completely random coin toss wether I get it back or not...)
As for the MySQL stuff. I generally have found mysql quite adequate when I give it several gigs of ram for it's various buffer pools. Also, several of the table are MEMORY type tables which does the same thing as making a ram disk. (with backups, of course.)
I tried for doing a ramdisk type thing, it was just too much of a pain to do (especially the backing up part -- even a hot dump once a day would make the website cry during the process). Mainly, I ran out of time to set it up and sufficiently test it before moving to the new server.
I did look into replication as a good way of doing the DB back up, but again, ran outta time. Additionally, most tutorials and guides and such are geared towards teaching you about server to server replication, whereing I was thinking about running client->client replication on the same machine.
Finally (promise) I'll probably install memcache at some point. I wanted APC for the precompiling and code caching it does -- as I've discovered that it's shared memory space is HIGHLY unreliable. (Maybe just my setup, but I can NOT get constant results. I store something, the refresh a page that "pulls" that something -- it's a completely random coin toss wether I get it back or not...)
Are you still planning to put 2GB sticks in the RAM slots or have you done it already?
speak englishchuyskywalker wrote:
No, the 7800 is my main machines card. lol, a server wtih a 7800 would be silly.
As for the MySQL stuff. I generally have found mysql quite adequate when I give it several gigs of ram for it's various buffer pools. Also, several of the table are MEMORY type tables which does the same thing as making a ram disk. (with backups, of course.)
I tried for doing a ramdisk type thing, it was just too much of a pain to do (especially the backing up part -- even a hot dump once a day would make the website cry during the process). Mainly, I ran out of time to set it up and sufficiently test it before moving to the new server.
I did look into replication as a good way of doing the DB back up, but again, ran outta time. Additionally, most tutorials and guides and such are geared towards teaching you about server to server replication, whereing I was thinking about running client->client replication on the same machine.
Finally (promise) I'll probably install memcache at some point. I wanted APC for the precompiling and code caching it does -- as I've discovered that it's shared memory space is HIGHLY unreliable. (Maybe just my setup, but I can NOT get constant results. I store something, the refresh a page that "pulls" that something -- it's a completely random coin toss wether I get it back or not...)
lol, I understood everything except the bottom two paragraphs, i'm not that informed on server stuff.polarbearz wrote:
speak englishchuyskywalker wrote:
No, the 7800 is my main machines card. lol, a server wtih a 7800 would be silly.
As for the MySQL stuff. I generally have found mysql quite adequate when I give it several gigs of ram for it's various buffer pools. Also, several of the table are MEMORY type tables which does the same thing as making a ram disk. (with backups, of course.)
I tried for doing a ramdisk type thing, it was just too much of a pain to do (especially the backing up part -- even a hot dump once a day would make the website cry during the process). Mainly, I ran out of time to set it up and sufficiently test it before moving to the new server.
I did look into replication as a good way of doing the DB back up, but again, ran outta time. Additionally, most tutorials and guides and such are geared towards teaching you about server to server replication, whereing I was thinking about running client->client replication on the same machine.
Finally (promise) I'll probably install memcache at some point. I wanted APC for the precompiling and code caching it does -- as I've discovered that it's shared memory space is HIGHLY unreliable. (Maybe just my setup, but I can NOT get constant results. I store something, the refresh a page that "pulls" that something -- it's a completely random coin toss wether I get it back or not...)
Hadn't played w/ MEMORY tables, closest I've come is HEAP I'm going to look into that, thanks for the tip.chuyskywalker wrote:
As for the MySQL stuff. I generally have found mysql quite adequate when I give it several gigs of ram for it's various buffer pools. Also, several of the table are MEMORY type tables which does the same thing as making a ram disk. (with backups, of course.)
I tried for doing a ramdisk type thing, it was just too much of a pain to do (especially the backing up part -- even a hot dump once a day would make the website cry during the process). Mainly, I ran out of time to set it up and sufficiently test it before moving to the new server.
I did look into replication as a good way of doing the DB back up, but again, ran outta time. Additionally, most tutorials and guides and such are geared towards teaching you about server to server replication, whereing I was thinking about running client->client replication on the same machine.
Finally (promise) I'll probably install memcache at some point. I wanted APC for the precompiling and code caching it does -- as I've discovered that it's shared memory space is HIGHLY unreliable. (Maybe just my setup, but I can NOT get constant results. I store something, the refresh a page that "pulls" that something -- it's a completely random coin toss wether I get it back or not...)
EDIT: Whoops, look like they just renamed HEAP tables. News to me:
http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html
"The MEMORY storage engine creates tables with contents that are stored in memory. Formerly, these were known as HEAP tables. MEMORY is the preferred term, although HEAP remains supported for backward compatibility."
I'm not famaliar with the amount of data you're dealing with, so a mysqldump might just be infeasable. So the only other real option (which you point out) would be replication.
I've been doing the same digging for client->client replication. Other than running two simultaneous instances of MySQL, they definitely don't make it easy. Plus MySQL's replication always leaves me a little wanting, I started out working w/ SQL Server, and I guess I was spoiled on a lot of features for a long time. I remember cussing MySQL 3.x.x (no stored procedures, views, difference/intersect, multimaster replication, etc, etc, ad naseum). The replication support is light years beyond what MySQL can offer (snapshot, merge, transactional - pushes or pulls, middle tier distributors, scales in every direction).
I haven't played with APC, but I can *HIGHLY* recommend memcache. Its unbelievably scalable, reliable, and the API is awesome. Can't say enough good things about it.
I'm impressed you have as much time to spend working on the website as you do! We all really do appreciate it. Great stuff!
Also, if there's ever anything I can do to help out, just let me know. I'd be glad to give you a hand with anything. I know a whee bit about the administrative stuff, but I'm a much better developer (php, mysql, (x)html, css, javascript).
Last edited by jon3k (2006-05-11 10:58:17)
I wish I could have so much Ice Sticks. I just have 1024 of Ram
God Damn Yew Rich
the pics wont load
Because this is an 8 month old thread.
x ?