Something big is coming....

[TPerry]

Time to give @Slavik a hard time... exactly how often do we need to turn it if we want to do it ourselves?
Till it's done, once every hour, or what?

 

[max diggle]

everything maybe

 

[Slavik]

Well today has been a long day

 

[Daniel Hood]

Awesome!

 

[Alpha1]

Looks good.

 

[DisAlex]

It's been a REALLY long day. Slavik has done a FANTASTIC job with the migration, I'm totally impressed! We still have a lot of work to do such as search and minor problems but we are open and in good shape.

 

[digitalpoint]

With permission of the forum owner

### Original version created by Shawn Hogan  ###

Lol... I wish I would have kept track of how many hours I put into creating the original version (of course, I never intended anyone to use it so it was totally crap code and hardcoded for my site). Just nice to see Slavik and Jake make it something more useable for others... I know if I had to rely on the native importer we probably would never have migrated... being down for days just isn't an option.

 

[DisAlex]

I would not have considered doing this without that tool. Days of downtime was also not a possibility for us! Awesome job!

 

[Jim Boy]

Welcome aboard - you've knocked my board back to third place

Interesting sounding setup you have, although I'd say you could probably trim it back somewhat, I'd be interested to compare notes.

 

[DisAlex]

Thanks for the welcome Jim! All of those are Virtual Machines running on 2 Hypervisors that also run our other web sites so I can bring CPU and RAM up and down at will. I pointed a lot of horsepower at the boards for the conversion, I wanted as little downtime as possible and we ended up being closed for about 17 hours start to finish which I feel is great for a board our size. In the end I gave the DB server 80 Gig of Ram so it was actually bigger than our database size. Now that we are up and running I can look at loads and dial these servers back if I want to but unless I have somewhere else to use it, not really a lot of sense. In March I should have new Hypervisors anyway, HP DL 380 G 9's!

 

[DisAlex]

2400 users online, Slavik is reindexing search and the Database server load is reading .81, .79, .68
Maybe I should be concerned about the climbing load?

 

[Slavik]

MORE RAM

 

[Naz]

There's plenty here: http://www.downloadmoreram.com/

 

[Amaury]

MORE RAM

MORE CAKE!

 

[DisAlex]

total used free shared buffers cached
Mem: 86656636 49930224 36726412 184 434112 2852424
-/+ buffers/cache: 46643688 40012948
Swap: 2097148 0 2097148

 

[Jim Boy]

You cant just put in a MySQL/MariaDB server with a heap of RAM and expect it to do the job. You really need to tune it. Our db server only has 15GB of RAM, yet we have had 8000 concurrent users - the database cruised through that, instead core failings in the XF code start to come into play at those magnitudes. Throwing more RAM in is a complete waste of money.

 

[Slavik]

You cant just put in a MySQL/MariaDB server with a heap of RAM and expect it to do the job. You really need to tune it. Our db server only has 15GB of RAM, yet we have had 8000 concurrent users - the database cruised through that, instead core failings in the XF code start to come into play at those magnitudes. Throwing more RAM in is a complete waste of money.

You forget.

 

[m1ne]

You cant just put in a MySQL/MariaDB server with a heap of RAM and expect it to do the job. You really need to tune it. Our db server only has 15GB of RAM, yet we have had 8000 concurrent users - the database cruised through that, instead core failings in the XF code start to come into play at those magnitudes. Throwing more RAM in is a complete waste of money.

I've had 12,000 concurrent users on 16gb ram total, you're absolutely right. Though 15,000 crashed the server, cpu fault though.

 

[DisAlex]

You cant just put in a MySQL/MariaDB server with a heap of RAM and expect it to do the job. You really need to tune it. Our db server only has 15GB of RAM, yet we have had 8000 concurrent users - the database cruised through that, instead core failings in the XF code start to come into play at those magnitudes. Throwing more RAM in is a complete waste of money.

I realize that, problem is when you are initially migrating over you don't know how much you need. Since the RAM exists in the hypervisors anyway why not assign it? After a bit, if it's more than I need I'll assign it somewhere else.
The import process went a LOT faster after we increased the RAM. These are virtual machines so you aren't really taking any RAM in or out your just telling it how much the server can use

 

[Jim Boy]

I realize that, problem is when you are initially migrating over you don't know how much you need. Since the RAM exists in the hypervisors anyway why not assign it? After a bit, if it's more than I need I'll assign it somewhere else.
The import process went a LOT faster after we increased the RAM. These are virtual machines so you aren't really taking any RAM in or out your just telling it how much the server can use

Two issues - the migration is done and dusted, no point going over that. Second issue is that increasing the current RAM will make zero difference, increase it if you want, but you may as well change the color of the server case while you are at it. Trust me, you've already got oodles of RAM, much more than busier systems than yours. You've got to look at things like query cache size, too small and your db will be going needlessly back to disk and having to recalculate everything which has a hit on CPU and will make your site slower.