# SERVER DOWNTIMES <--- READ



## Dragoneer (Apr 6, 2006)

*Notice to all users:*
We are expecting unannounced downtimes between 30 to 60 minutes* to take place this weekend to perform full server upgrades. When we are ready, we will pull the server offline the moment it is ready to go. We will not give anymore notice than this. We will not be able to give a heads up.

We want this site to be faster than lightning, and so do you.

If you really, REALLY want to access FurAffinity during these down times, I suggest getting a Post-It note, writing down: _"System Error - Database responded: Too many connections!"_ and randomly stick it on your monitor whenever you click a link.

That is all.

* Actual downtimes may vary. Speed not guaranteed by Comcast. Act now and save 10%. Free shipping on all orders over $50. Not guaranteed to restore hair loss. May contain peanuts. Take orally. Not available in Canada. Offer expires 04/15/2007.


----------



## Tikara (Apr 6, 2006)

Alwight. Understood. We'll try and be pacient :3

... *twitches and stares at the door marked "FA Server"* Hurrys..... >_>


----------



## Zippo (Apr 6, 2006)

*nods* Got it. I was wondering about those.


----------



## Silver R. Wolfe (Apr 6, 2006)

*prepares my sticky note* It's a deluxe one that way I can't miss it.


----------



## Kasarn (Apr 6, 2006)

Post-it prepared and tested!


----------



## Vgm22 (Apr 6, 2006)

Ok, I have it locked in my brain. Will be waiting for the return of FA. -sits and camps out-


----------



## quamer (Apr 6, 2006)

OMG!!!!


----------



## Catamount (Apr 6, 2006)

Dragoneer said:
			
		

> Actual downtimes may vary. Speed not guaranteed by Comcast. Act now and save 10%. Free shipping on all orders over $50. Not guaranteed to restore hair loss. May contain peanuts. Take orally. Not available in Canada. Offer expires 04/15/2007.


:shock: 
what a deal! does it come in a suppository?


----------



## nrr (Apr 6, 2006)

Dragoneer said:
			
		

> We want this site to be faster than lightning, and so do you.


I, I'm afraid, do not agree with this comment.  I would personally rather the site be slicker'n snot.


----------



## Silver R. Wolfe (Apr 7, 2006)

nrr said:
			
		

> Dragoneer said:
> 
> 
> 
> ...



Sometimes snot isn't so slick... Like when you're sick and it gets all congested in there...


----------



## Dragoneer (Apr 7, 2006)

silverwolfe said:
			
		

> nrr said:
> 
> 
> 
> ...


I hate when it's all crusty and sharp, like angry green icicles.


----------



## Silver R. Wolfe (Apr 7, 2006)

Dragoneer said:
			
		

> silverwolfe said:
> 
> 
> 
> ...



*nods* Those are the worst kind, but if you know how to do it, they come out the easiest.  Course, I wouldn't know anything about that firsthand...  I... heard it from a friend...


----------



## Kaji Ryuuko (Apr 8, 2006)

What the hell...this was a topic about server down time and now it's about SNOT...-_- I really need to calm down...*goes to bed*


----------



## EzFoxie_Hentai (Apr 8, 2006)

Any idea when the visitor count will be working again? Its been down for ages...


----------



## Pinkuh (Apr 8, 2006)

EzFoxie_Hentai said:
			
		

> Any idea when the visitor count will be working again? Its been down for ages...



Hopefully if all goes well we will be able to re-instate the counters after we get the new hardware up and running.


----------



## Dragoneer (Apr 9, 2006)

Pinkuh said:
			
		

> EzFoxie_Hentai said:
> 
> 
> 
> ...


I'd just like to add that it's 1:40 am, and I just got home. Gushi, Scooter and I spent the later part of the evening reconfiguring the server and preparing it.

We're going to get started on file transfer soon. More updates on server to follow


----------



## Cerise (Apr 9, 2006)

It shall live again, Igor!


----------



## Midnite (Apr 9, 2006)

*sits patiently*


........i'm going to have nightmares of running away from globs of snot as they throw green icicles at me.


----------



## cesarin (Apr 9, 2006)

so.. how much 'til the server change?
the server as been up all day, just seen a 5 minute "server is in owner mode" thing at midnight


----------



## Dragoneer (Apr 9, 2006)

cesarin said:
			
		

> so.. how much 'til the server change?
> the server as been up all day, just seen a 5 minute "server is in owner mode" thing at midnight


Not sure. It should be tonight, but... then again, it could be tomorrow. I'd rather it be done right than done ASAP.


----------



## Final_Destiny (Apr 9, 2006)

will this fix whatever problem your having, which is causing the halt in the counts?


----------



## timoran (Apr 9, 2006)

I think the server is being changed now... because it's not responding.

Edit: Never mind.

Page generated in 219.56291 seconds (98.981% PHP - 1.019% MySQL [ 2 queries ])


----------



## yak (Apr 10, 2006)

Final_Destiny said:
			
		

> will this fix whatever problem your having, which is causing the halt in the counts?


NO, but it will add a lot of raw power, so the queries will run faster and the responce time would be within an acceptable range.

Seriuosly folks, please DO consider rethinking the queries and the database layout if needed. I know i am repeating myself for the 4'th or the 5'th time already, but come on... I can't stress this enouth. 
As an example i'll say that one of the temp servers at my work place is a single processor Athlon 1700+ 256DDR and a single PATA 80GB Seagate hard drive. The sites virtually hosted there yield 200 registered users and ~500 guests online. And almost no problems - it can host even more. One notice thou - all the scripts on the server are written by us...
Compare that to what you have here. Virtual hosting vs Dedicated hosting, 256Mb vs 4096Mb, 1.43MHz single vs PIV around 3GHz (3.04MHz dual soon), single PATA vs (possibly) SATA raid.
All i want to say that this just looks ridiculos...


----------



## Dragoneer (Apr 10, 2006)

yak said:
			
		

> Seriuosly folks, please DO consider rethinking the queries and the database layout if needed. I know i am repeating myself for the 4'th or the 5'th time already, but come on...


We are doing revisions to the database, too. We're working on how queries are handled, and trying to further do system refinements. As we progress requirements will further reduce and get more efficient.

Also, we don't have 4096MB, only 2048MB. 2GB of RAM. Yet. We're still on the temp server, trying to get things up. We'll be upgrading the system (hardware and software) quite a bit more in the near future.


----------



## timoran (Apr 10, 2006)

Hooooolyshit. FA is decent. DECENT I tells ya.

I should point out that I'm using it at 10 AM, but if it's this good at midnight, THEN I will be impressed.


----------



## Vgm22 (Apr 10, 2006)

timoran said:
			
		

> Hooooolyshit. FA is decent. DECENT I tells ya.



That I can agree with with. It not majorly lagging. Like it was.


----------



## Dragoneer (Apr 10, 2006)

timoran said:
			
		

> Hooooolyshit. FA is decent. DECENT I tells ya.
> 
> I should point out that I'm using it at 10 AM, but if it's this good at midnight, THEN I will be impressed.


We're still on the temp server as best as I can tell, despite some tweaks. when the ip address rolls over from .240 to .250 we should be live on the new server.


----------



## Vgm22 (Apr 10, 2006)

Dragoneer said:
			
		

> timoran said:
> 
> 
> 
> ...



Ok. Can you tell us what you've done so far? Like a timeline of when you started to what your doing now?


----------



## timoran (Apr 10, 2006)

Dragoneer said:
			
		

> timoran said:
> 
> 
> 
> ...



Heh, you can tell I've never used the temp server at 10 AM before, then.


----------



## Dragoneer (Apr 10, 2006)

Vgm22 said:
			
		

> Dragoneer said:
> 
> 
> 
> ...


Woke up, ate a banana. Was still hungry, made a taco Hot Pocket. Then went to Joblandia, took some calls, did some work...

OH! WAIT...  you mean on FA?

*Friday:* Went to colo, registered our network IDs and got access cards to the restricted areas so Dragoneers and Scooters can enter and exit the building at ease. Motherboard replacement had not arrived.
*Saturday: *Motherboard arrived, drove back up to the colo, re-configured and re-installed the server with Scooter and Gushi. Remounted the server in the rack, did some quick testing, everything POSTed fine, machine was healthy. Gushi checked some configuration tests and got the server ready to transfer files. I arrived home shortly before 2:00am. Spent half an hour looking for one of my cats who go outside...
*Sunday: *Nothing was able to be accomplished to my awareness. I had to work a 12 hour shift. Things may have happened, but I am not sure. I spent the day running on two hours of sleep. Got home, went to bed. Entire weekend was blown working on FA and a minimum lack of sleep.
*Monday: *Only got three hours of sleep due to a massive headache which kept me tossing and turning. Played with cats, worked on total rewrite of FA FAQ and TOS. Asked Gushi at 8:00am on server status. he noted he was too busy Sunday night with work-related items to get things finalized. Said he would try today.
*
Total time spent driving: *11 hours, $90 expenses (and no reimbursements!)
*Total time spent at colo: *8 hours

FA is like a second job that costs me a shitload and earns me nothing! Heh heh.


----------



## riceball (Apr 10, 2006)

Dragoneer said:
			
		

> I'd rather it be done right than done ASAP.



Sane voice heard.

http://httpd.apache.org/test/flood/

Install it, because it's pretty apparent that it's not been.  Learn how to set up a farm, XML is easy to write.  Run it.  A lot.  Often.  Like, with every code/schema change often, before it's put on the live site.

Umm..  And if the schema is still anything like what got posted during the SQL injection hacks..  Then something like http://www.devshed.com/c/a/MySQL/An-Introduction-to-Database-Normalization/2/ should be read, studied, and applied to the schema with vicious force.  100+ columns just for user data is /BAD/.  I can't imagine what the rest of the design looked like.

(INDEX is your friend too.)


----------



## KAI Kauske (Apr 10, 2006)

Dragoneer said:
			
		

> Vgm22 said:
> 
> 
> 
> ...



But is FA a labour of love?


----------



## Vgm22 (Apr 10, 2006)

Dragoneer said:
			
		

> Woke up, ate a banana. Was still hungry, made a taco Hot Pocket. Then went to Joblandia, took some calls, did some work...
> 
> OH! WAIT...  you mean on FA?
> 
> ...



Whoa damn! Thank you for busting your ass, aswell as everyone else that bust thiers, to get FA at 100%.


----------



## Dragoneer (Apr 10, 2006)

KAI Kauske said:
			
		

> But is FA a labour of love?


Well, there's definately labour... and some love. I still don't know which there's more of. =P


----------



## Emerson (Apr 10, 2006)

Dragoneer said:
			
		

> FA is like a second job that costs me a shitload and earns me nothing! Heh heh.



Your dedication to providing us a nice little place to post our anthro smut is touching. Seriously.

No, _seriously_.


----------



## Dragoneer (Apr 10, 2006)

Emerson said:
			
		

> Your dedication to providing us a nice little place to post our anthro smut is touching. Seriously.
> 
> No, _seriously_.


*pr0n is serious business.*

And I'm a smutty businessman wearin' leather underpants. Heh heh heh!


----------



## KAI Kauske (Apr 10, 2006)

Dragoneer said:
			
		

> Well, there's definately labour... and some love. I still don't know which there's more of. =P



I'm sure it's more labour, networking and managing a large site is togh work...


----------



## Emerson (Apr 10, 2006)

Dragoneer said:
			
		

> Emerson said:
> 
> 
> 
> ...



See, I knew there was a reason I stuck with FA.


----------



## Suule (Apr 10, 2006)

Dragoneer said:
			
		

> *pr0n is serious business.*
> 
> And I'm a smutty businessman wearin' leather underpants. Heh heh heh!



Hmrrrr... *evil stare*


----------



## cesarin (Apr 10, 2006)

Dragoneer said:
			
		

> Vgm22 said:
> 
> 
> 
> ...



lies, it gives you the joy of being spanked, then insulted, and then huged and praised by horrible furs


----------



## Keet (Apr 11, 2006)

I can see this upgrade going like so..

- good is that there will be faster page loads.
- faster page loads means easier to browse.
- easier browsing means more comments, views, uploading more pictures.
- and all those people able to do things faster then tell their friends how happy they are with FA.
- friends come and do all that stuff too - more art! yay!
- FA gets so much traffic, it ends up slow again.. doh! hehe 

if nothing else, you can always setup the old FA server as a cache


----------



## uncia2000 (Apr 11, 2006)

Keet said:
			
		

> I can see this upgrade going like so..
> 
> - good is that there will be faster page loads.
> - faster page loads means easier to browse.


Depends on how much of the slowness was down to inefficient SQL queries... i.e. whether the major bottleneck was more CPU-side or disk-side.
If primarily the latter, we'll probably still have issues with transactions queueing leading those connection errors, sooner rather than later. (And if we're failing to release locks asap on logical transactions that probably isn't helping, either).

Shall see.



			
				Keet said:
			
		

> - easier browsing means more comments, views, uploading more pictures.
> - and all those people able to do things faster then tell their friends how happy they are with FA.
> - friends come and do all that stuff too - more art! yay!
> - FA gets so much traffic, it ends up slow again.. doh! hehe


Yep.

It doesn't pay to advertise a site until you've got a workable routemap on scaleability issues.


----------



## Dragoneer (Apr 11, 2006)

uncia2000 said:
			
		

> Depends on how much of the slowness was down to inefficient SQL queries... i.e. whether the major bottleneck was more CPU-side or disk-side.


That's why we're investing in 4 10,000 RPM 150GB WD Raptor drives.


----------



## Emerson (Apr 11, 2006)

Dragoneer said:
			
		

> uncia2000 said:
> 
> 
> 
> ...



Isn't that what powers the Enterprise, or something? Dude, this is going to be FAST.


----------



## Keet (Apr 11, 2006)

before investing in $1400 of hard drives you might want to check if thats where you need it, you can pick up 1GB sticks of DDR400 ECC registered memory for only about $120 on newegg

look at your data and log paths, make sure your not using the same disk

ram is a big one though, the more you can hold in memory, the less you have to go looking for stuff on slow hard disks (even 15K RPM disks are slow compared to the speed of ram)


----------



## Dragoneer (Apr 11, 2006)

Keet said:
			
		

> before investing in $1400 of hard drives you might want to check if thats where you need it, you can pick up 1GB sticks of DDR400 ECC registered memory for only about $120 on newegg
> 
> look at your data and log paths, make sure your not using the same disk
> 
> ram is a big one though, the more you can hold in memory, the less you have to go looking for stuff on slow hard disks (even 15K RPM disks are slow compared to the speed of ram)


Two steps ahead of you.

The hard drives are not an investment which is going to take right away. We've already invested in getting another 2GB of memory, and that upgrade should take place in the next one to two weeks.

The hard drives upgrade will take place, however, as we will convert the current server into a pure file server. We'll be getting an entirely new case, dropping the current server Gecko down to a 2U from a 4U, and investing in another 2U quad-core Opteron server for processing database queries and further feature expansion.

We have our roadmap on hardware planned to ensure full scalability of the site and to promise site speed efficiency for now and into the future.

It is our ultimate goal to streamline and futureproof FA as much as possible and to prevent the next "Great Slowdown". Along with our upcoming full site redesign and makeover, we'll be well equipped for life, the universe and everything.


----------



## Dragoneer (Apr 11, 2006)

Emerson said:
			
		

> That's why we're investing in 4 10,000 RPM 150GB WD Raptor drives.



Isn't that what powers the Enterprise, or something? Dude, this is going to be FAST.[/quote]
HA! 

Well, in a massive DB once CPU and memory slowdowns/capacities are taken care of, the next big "hurdle" to overcome is hard drive speed. Raptors are the highest efficiency consumer SATA drives on the market, so they should be more than enough. We're currently looking at how best to optimize spending to equate the best value per performance.


----------



## nrr (Apr 11, 2006)

Keet said:
			
		

> ram is a big one though, the more you can hold in memory, the less you have to go looking for stuff on slow hard disks (even 15K RPM disks are slow compared to the speed of ram)


Realistically, the absolute fastest you'll ever see data coming from your disks is *150MB/s*.  This has to do with host adapter/disk controller throughput limitations, not to mention the limitations imposed by the PCI bus.

You'll be seeing data coming from your RAM far faster.  I'm talking an order of magnitude faster.  Perhaps even snappier than that.  FWIW, I can pull *2GB/s* across my RAM on my dual Opteron box sitting here while my disk throughput (albeit on UATA/100 disks) averages about *80MB/s* given that I have to seek for what I want to manipulate first.

Profile your code to figure out which operations are taking the longest time.  Blindly throwing money around at the problem with no intelligence won't fix anything.


----------



## Emerson (Apr 11, 2006)

Dragoneer said:
			
		

> It is our ultimate goal to streamline and futureproof FA as much as possible and to prevent the next "Great Slowdown". Along with our upcoming full site redesign and makeover, we'll be well equipped for life, the universe and everything.



"42."

Anyhow, it's all technobabble to me. I know where the gas and keys in my car go; I know that I need to plug my computer in before it will work. Because I am crazy, I trust y'all to do what needs to be done to make FA run as smooth as possible.


----------



## Dragoneer (Apr 11, 2006)

nrr said:
			
		

> Realistically, the absolute fastest you'll ever see data coming from your disks is *150MB/s*.  This has to do with host adapter/disk controller throughput limitations, not to mention the limitations imposed by the PCI bus.


True, but we'll have maxed out our Nocana motherboard's RAM at 4GB, an unfortunate limitation. RAM will be upgraded first before anything else.


----------



## riceball (Apr 11, 2006)

Dragoneer said:
			
		

> It is our ultimate goal to streamline and futureproof FA as much as possible and to prevent the next "Great Slowdown". Along with our upcoming full site redesign and makeover, we'll be well equipped for life, the universe and everything.



I would seariously run load tests on the SQL.  (*hint*hint* Install Flood.)

A simple set of queries to pull out just a block of rows shouldn't be taking more than half a second under the usual evening traffic.

New harddrives ultimately will only mean more storage capacity, and if FA doesn't need ~600GB of storage data /right now/, then it should be something to trickle down in when it's needed.  Faster CPUs will reduce the wait time for image scaling.  More memory for holding RAW image data and Apache kids.

Also..

I would rather the site be BUTT UGLY and /FAST/..  Than pretty and slower than a frozen slug in the Antarctic in winter (August through June).  Eyecandy should /always/ come last.  Finding out exactly what's causing SQL to take an eternity and fixing /that/ should be the highest priority.


----------



## Arshes Nei (Apr 11, 2006)

The great slowdown would be a memory processor issue iirc, it would make sense, not a storage issue.  I mean I'm no geekbling to be sure, but even I know it's not what you store but how you process it.

You definitely need more on the programming side than the hardware side since even when FA 1.0 was up there were ways to make it run reasonably fast.


----------



## nrr (Apr 11, 2006)

Dragoneer said:
			
		

> True, but we'll have maxed out our Nocana motherboard's RAM at 4GB, an unfortunate limitation. RAM will be upgraded first before anything else.


You're going to start needing to learn how to cluster.

I hate to say it, but I told you so.


----------



## Dragoneer (Apr 11, 2006)

Arshes Nei said:
			
		

> The great slowdown would be a memory processor issue iirc, it would make sense, not a storage issue.  I mean I'm no geekbling to be sure, but even I know it's not what you store but how you process it.


Yeah, I'm not saying it is a storage issue at all. I'm just saying it's an eventual upgrade path for the future.


----------



## Dragoneer (Apr 11, 2006)

nrr said:
			
		

> You're going to start needing to learn how to cluster.


I agree fully.


----------



## uncia2000 (Apr 11, 2006)

riceball said:
			
		

> I would rather the site be BUTT UGLY and /FAST/...


 A riceball after my heart ^^
Yep, and well clear of some of the UI issues that can make users weep in despair, if they're not careful; e.g. http://www.furaffinity.net/journal/9345/ (I fell for that one, too)

The tech work is wide-ranging enough to be split across various buddy teams (at the least, perhaps, data I/O layer and UI presentation/customisation [splitting the UI aspects into submission-related and user control panel/admin panels/other, if required]) with at least one person keeping an eye open as to improvements in each area.
... Still seems to be somewhat centralised, despite having had a fair number of offers of free help. 



			
				riceball said:
			
		

> Eyecandy should /always/ come last.  Finding out exactly what's causing SQL to take an eternity and fixing /that/ should be the highest priority.


If the eyecandy can be handled separately (new piccies of Fender, say), that's not an issue.

Yep, we've been around the SQL/DB2 issues before: haven't heard back on my last few posts here or on the admin boards.
If there are thumbnails on the base submissions table, kick them out: the whole submissions table should be able to sit in-core, keyed on submission #, etc., and the data filtering will be done in a flash, even if the SQL coding is inefficient.
At the same time, the locking issues can be addressed, since it's obvious that updates are happening (new comments being inserted in the journals, say) and then the users are left hanging waiting for locks to be released to update comment counters, etc. In theory we have row level locking (sure doesn't behave like that!), so if that's not being over-ridden there must be something along the lines of a failure to COMMIT the end of the logical transaction or the engine is otherwise failing to release resources in a timely fashion.
(etc. etc. )

Yeah, but I'm happy if upgrades buy us time (for which, *many* thanks, of course ) to carry out such work.


----------



## Dragoneer (Apr 11, 2006)

uncia2000 said:
			
		

> riceball said:
> 
> 
> 
> ...


Correct. Eyecandy should always come after functionality and efficiency, but in this case, eyecandy is being done by seperate members of the team. Namely, myself and those artists with whom I am working in conjunction.

*Coding Team:* Jheryn, Tos, Crypto
*Hardware Team:* Gushi, Scooter, Dragoneer
*UI Team:* Dragoneer

So, we've got people working on different aspects of the site. Now that I've handled the server issues, I can resume work where I need to focus on improvements for the site.

I'll probably pull on some other people to the UI team, but for now I'm focusing on that almost primarily by myself, then we'll no doubt go through some revisions.


----------



## uncia2000 (Apr 11, 2006)

Dragoneer said:
			
		

> uncia2000 said:
> 
> 
> 
> ...


Every little helps. 

Neat, but we'd be hard pressed (*g*) to obtain an order of magnitude improvement in transaction throughput from HDD-side investment even if we're being clever with data handling.



			
				Dragoneer said:
			
		

> Well, in a massive DB once CPU and memory slowdowns/capacities are taken care of, the next big "hurdle" to overcome is hard drive speed.


Our database is still pretty "small", IMHO. 
(The number of rows and access paths onto the data are more important than the size of the artwork submission file tagged onto each row on that table, since the number of artwork submissions we actually pull onto the UI at any one time is fixed by the UI design (browse screen, user page, etc.)).



			
				Dragoneer said:
			
		

> KAI Kauske said:
> 
> 
> 
> ...


Awwww..... 
*pat pats*


----------



## Dragoneer (Apr 11, 2006)

uncia2000 said:
			
		

> Dragoneer said:
> 
> 
> 
> ...


Oh, we'll need the power...  Trust me.


----------



## riceball (Apr 11, 2006)

Dragoneer said:
			
		

> *UI Team:* Dragoneer



(*psst*  I hate the message center entirely.  DA's UI is a /mess/.)

What'd be more appealing, is a tweak to the code, switch-case for query type, and have things, like, say..  A watch page come up, like your gallery, except it'd be submissions by the folks you're watching instead.  You'd never 'accidentally' purge the messages anymore, and have to run through your watch list like a headless chicken checking for missed entries.

Same with watches/watched by lists, sorted by preference.. Date, alpha, etc.

Journals, yadda..

Would remove the need for /more/ tables in the database.  Fewer queries too, I'd wager, since it probably takes an extra one for updating the message center table(s).

Other thing..  onMouseover..  Pop-up with user-icon, name, title.. Fine.. Yay.. Goody..  But the description of the submission?  That's pretty useless, especially on the right-hand column where it tends to get chopped off and thusly unreadable.  I'd get rid of the description aspect, personally.


----------



## riceball (Apr 11, 2006)

uncia2000 said:
			
		

> Our database is still pretty "small", IMHO.



All the better time to get the SQL straightened out.  The bigger it gets, the potentially slower the site is going to get.

Be like trying to find a word in a dictionary that's been ran through a blender.


----------



## uncia2000 (Apr 11, 2006)

Dragoneer said:
			
		

> *Coding Team:* Jheryn, Tos, Crypto
> *Hardware Team:* Gushi, Scooter, Dragoneer
> *UI Team:* Dragoneer
> 
> So, we've got people working on different aspects of the site.


I can't see over shoulders to confirm that Jheryn, Tos and Crypto are code-cutting together as a buddy team at this very second.
However, if we all can actually get the impression that that's how things are being done by results of their work, all fair and well... 

Just checking, but I thought that what's on your plate was the UI design. Good to have this separated out (even though I could've sworn you have other stuff on your plate, too ).

The UI presentation layer that I noted in my division-of-labor example is the mapping of the data retrieved/data to be sent from the UI back onto the DB; i.e. a discrete element on the code cutting side from the actual data I/O layer, which revolves around the SQL code.
If our tech team is somehow buddy working across _all_ of those areas simultaneously at present and _that is working_, we can take reassurance from that.
The impression, however, is that the code dev is still being handled as a single ball of dough with only one individual trying to prod away at that, at any one time. And no person with oversight on improvements to the UI presentation layer code.
(IMO, a long way short of what I was noted and you replied to).
If that's the case, believe me there are certainly smarter ways to work than that, given the availability of zero-cost labor.



			
				Dragoneer said:
			
		

> Now that I've handled the server issues, I can resume work where I need to focus on improvements for the site.


----------



## nrr (Apr 11, 2006)

Dragoneer said:
			
		

> Oh, we'll need the wasted power...  Trust me.


Fixed.

Faster disks will only buy you more heat and more strain on your power supply.  In all practicality, consider disks expendable; they fail, and they fail often.

7200 r/min disks are fine, and they're even more fine when you place a huge cache in front of them (*hint* *go get a nice RAID card* *hint*) when you're dealing with databases.  Your fileservers can instead use some sort of network-replicated scheme that's cheaper than RAID to achieve better use of disks.

It's meaningless to invest so much in something that will fail irreparably so soon down the road.


----------



## uncia2000 (Apr 11, 2006)

Dragoneer said:
			
		

> uncia2000 said:
> 
> 
> 
> ...


Yep; no doubt 'bout that, 'yena, but a pair of scissors works better when cutting through the likes of persistent table deadlocking issues.


----------



## Dragoneer (Apr 11, 2006)

nrr said:
			
		

> *hint* go get a nice RAID card


Oh, you mean like the 3ware SATA RAID controller card with 128MB onboard RAM which we already have in the Gecko server? Ten steps ahead of you. Let's assume Dragoneer knows hardware like the back of his hand, build awesome rigs... and knows next to jack about 94% of all coding (which is the truth). 

And that would be the right assumption.  :lol:


----------



## yak (Apr 11, 2006)

personally i'd have voted for making the old server a database, rather then the file server. it would be the fair division. SQL consumes CPU, RAM and I/O in, uhmm, BIG proportions - somewhat bigger then PHP and apache altogether. keeping them separated would also mean still sticking to the 'three-tier' website schema rather then just introducing a fourth redundant (at the moment, IMO) tier.

[edit]
i got this mental image of an old medieval man left alone to guard the narrow , one foot-wide pass along the side of the cliff. and the scenery of that old man throwing stones at the invading 500k+ army from the top of the said cliff, making the soldiers fall onto the deadly rocks below, thus kepping the entire army from entering the kindom.

i really got to make FA comix one day... all i have to do is to learn to use a pencil.


----------



## uncia2000 (Apr 11, 2006)

nrr said:
			
		

> Dragoneer said:
> 
> 
> 
> ...


No fair, nrr. I was reading back on the previous posts whilst typing... ^^



			
				nrr said:
			
		

> Faster disks will only buy you more heat and more strain on your power supply.  In all practicality, consider disks expendable; they fail, and they fail often.
> 
> 7200 r/min disks are fine, and they're even more fine when you place a huge cache in front of them (*hint* *go get a nice RAID card* *hint*) when you're dealing with databases.  Your fileservers can instead use some sort of network-replicated scheme that's cheaper than RAID to achieve better use of disks.


Those sound like wise words.

Still won't get that full order of magnitude improvement that is so easily achieveable by sticking key table data in core or improving any SQL that is found to have serious "issues", but in terms of stability/availability is a very smart move.

Hey, just give me a good ol' parallel sysplex setup with full datasharing across a world of HDDs and I'll be happy. (Erm, sorry, wrong platform :roll: )


----------



## Dragoneer (Apr 11, 2006)

uncia2000 said:
			
		

> nrr said:
> 
> 
> 
> ...


One thing we would strive with the drives would be full parity, so if one drive fails, we've lost nothing.


----------



## CyberFoxx (Apr 11, 2006)

I'm personally just curious, are you running the dual-Xeon setup in 32-bit, or 64-bit mode? I know from my own experiance that even my Celeron D 2.93Ghz was faster in 64-bit mode than in 32-bit mode. I just had to switch back to 32-bit mode because stupid win32codecs and netscape-flash don't work in 64-bit mode. (Damn people and using WMV to encode Anime Music Videos...)

Only problem I can see is that 64-bit mode does need more RAM than 32-bit mode. (Was quite fun running Gentoo in 64-bit mode with only 512MB of PC3200.) But if that dual-Xeon setup already has 2GB, and you'll be getting 2GB more, then it should be ok.

Anyway, I was just curious. Also, if you are running in 32-bit mode right now, 64-bit might be something to look into. Maybe as a future "upgrade" somewhere quite a ways down the road. Just make sure everything you run is 64-bit safe and researched all the quirks that come with it first. ^_^


----------



## Dragoneer (Apr 11, 2006)

CyberFoxx said:
			
		

> I'm personally just curious, are you running the dual-Xeon setup in 32-bit, or 64-bit mode?


64-bit optimized FreeBSD


----------



## CyberFoxx (Apr 11, 2006)

Dragoneer said:
			
		

> 64-bit optimized FreeBSD



Ohh, very nice. Sure, I'm a huge fan of Linux, but even I have to admit that BSD rocks. You at least get a huge thumbs-up from me. ^_^


----------



## Keet (Apr 11, 2006)

Dragoneer said:
			
		

> nrr said:
> 
> 
> 
> ...




I hope that card has a battery backup option that your using?
You'd be amazed at the difference having a write back cache vs write thru has on I/O's.


----------



## yak (Apr 11, 2006)

CyberFoxx said:
			
		

> Dragoneer said:
> 
> 
> 
> ...


seconded. both of you.  *got 2 thumbs left*

good thing the controller was not a cheap piece of software crap designed only for use with windows that *looked* like it was a hardware one.

oh, i got to tell this. i've been LMAO all day long. 
so here is this IBM xSeries 306m type 8491 server we have lying around the office for a few days now, unsucesfully trying to get it to work with at least some flavour of *.nix. try as we might, none of them seem to find any of the two 80GB 10k SCSI hard drives, and neither the RAID1 array out of them in the system because the crappy SAS/SATA controller designed to run on windows only. we even got as far as contacting linux kernel developers concearning this issue...
but that is irrelevant. ok, so there was this 'system error' led on the front panned that went on lid till we finally noticed it today. users manual for the server had nothing on it, so we phoned the company and asked them.
dig their responce - "it lids every time there is no windows software installed in the system". *cough* system error........ windows... lol


----------



## yak (Apr 11, 2006)

Dragoneer said:
			
		

> We're currently looking at how best to optimize spending to equate the best value per performance.


$5
it always worked for me. i've spent in either on a new book or a pack of cookies to consume while surfing the net in search of some mans. 

PS
oh, yeah - and some of those ASM demos.. after watching them i always feel  a complete n00b and that stimulates me to go and do something about it.


----------



## nrr (Apr 11, 2006)

Dragoneer said:
			
		

> Let's assume Dragoneer knows hardware like the back of his hand, build awesome rigs... and knows next to jack about 94% of all coding (which is the truth).


Awesome rigs... like your dual Opteron box with a fucked up DIMM setup?

Please.


----------



## nrr (Apr 11, 2006)

Dragoneer said:
			
		

> One thing we would strive with the drives would be full parity, so if one drive fails, we've lost nothing.


The point wasn't that you hadn't planned on a disk failing.  Rather, the point was that you were making a poor decision on the purchase of something considered to be expendable.

Yes, you have a plan in place to keep data safe in the event of a disk failure.  What is your plan, however, to _replace_ that failed disk?


----------



## Dragoneer (Apr 11, 2006)

nrr said:
			
		

> Dragoneer said:
> 
> 
> 
> ...


HEY! LAY OFF MY E-PENIS!

My Opti-box's motherboard is kickass performance, I don't care what you say. =P Sure, the memory is not as efficient as it could be, but it's made for graphics, not data humping. It's still one of the fastet Opteron 940-based motherboards that also comes equipped with superfly SLI support.

I traded individual memory slots for twin nVidia 3450 Quadros. Over $2,500 in graphics setup alone (and another $1,100 in my gaming rig). The Opti-box has 4GB of RAM, and the CPUs don't seem to mind. I'm sure there's a bit of bottlenecking in there, but it's a $250 board compared to the average dual-CPU slot board which costs double the price.

Show me a great high-bandwidth SLI motherboard for $250 that has dualbanks and equal performance for dual CPUs and I'll consider buying it.

Until then, LAY OFF MY PRECIOUS!

This would not be my choice for server motherboards. And my gaming rig doesn't get much better than it is, so... yeah. My motherboard may not agree with you, but the rest of my hardware is lubricatingly slick.


----------



## Dragoneer (Apr 11, 2006)

nrr said:
			
		

> Dragoneer said:
> 
> 
> 
> ...


Everything has to fail sometime. CPU and RAM are my first upgrade paths, HDs second. Everything will fail some time, and I view them all as expendable. Which is one reason when I invest in hardware I buy shit with a lifetime warranty.


----------



## cesarin (Apr 11, 2006)

I tought Xeons were awfully bad in 64 bit mode? 
I heard a lot that they're way slower than in 32 bit mode... ( or maybe as it just under windows? )
just wondering 'cause *hugs his AMD* ^______^



and let's hope everything goes fine Dragoneer, except that seems the FA keeps growinggrowing and growing, and its eating you slowly x_X


----------



## CyberFoxx (Apr 11, 2006)

cesarin said:
			
		

> I tought Xeons were awfully bad in 64 bit mode?
> I heard a lot that they're way slower than in 32 bit mode... ( or maybe as it just under windows? )



Actually, Intel is using AMD's 64-bit code in the new Xeons, Pentium IVs, and Celerons. They've just renamed it to EM64T. It's all because Microsoft said they don't want to support two different 64-bit instruction sets.

Oh, and it's the Itainiums that were the really crappy 64-bit/32-bit CPUs. Although, they do make good heaters...


----------



## Laik (Apr 11, 2006)

CyberFoxx said:
			
		

> cesarin said:
> 
> 
> 
> ...



hahaha xD Indeed, I think you could open a barbeque store with a few of those. And I speak for personal experience.


----------

