Planned downtime: OS upgrade

[loftar]

1) you have some disbalance on sda and sdb, i think from dm-1 (don't split read/write (data) on both disk)

Yes, it's probably balanced towards sda. Since it isn't striped, that's probably its natural inclination. :)

2) did you test ext4 for this project?

No, because ext4 still has a hard limit on subdirectories which is too small for some of the structures that the server uses.

3) how many files/dirs with data?

I don't have any exact numbers, but I'd approximate it to about 250,000 directories and some 550,000 files.

4) on disk data size?

The filesystem holding the game data currently uses 93 GB, but then it also still contains the W5 maps and also a backup copy of every map file (including the W5 ones).

5) mem on server?
6) in memory server process size?

The server has 12 GB of RAM, whereof the game server normally uses somewhere between 6-8 GB. Usually, around 3-4 GB are free for the block cache.

7) did you defragment xfs with xfs_fsr?

No. I guess I wouldn't mind trying, but I doubt fragmentation is the issue, since it isn't a matter of the filesystem just performing steadily bad, but rather of sudden spikes in I/O latency. This is also part of the reason why I suspect that log flushing is part of the problem. I was hoping that Linux 3.2 would solve some of that since it uses delayed logging in XFS by default, but alas...

[painhertz]

Turn off logging?

[Zluka52]

BTW what disk you have? simple SATA? usualy it have about 100-150 iops limit. and you almost near it.

1) you have some disbalance on sda and sdb, i think from dm-1 (don't split read/write (data) on both disk)

Yes, it's probably balanced towards sda. Since it isn't striped, that's probably its natural inclination.

Can you host all LVM volumes on softraid device? Since use only one disk, slowdown softraid io.

2) did you test ext4 for this project?

No, because ext4 still has a hard limit on subdirectories which is too small for some of the structures that the server uses.

3) how many files/dirs with data?

I don't have any exact numbers, but I'd approximate it to about 250,000 directories and some 550,000 files.

if you use hash tree dir structure, it is not a problem for ext4.

4) on disk data size?

The filesystem holding the game data currently uses 93 GB, but then it also still contains the W5 maps and also a backup copy of every map file (including the W5 ones).

5) mem on server?
6) in memory server process size?

The server has 12 GB of RAM, whereof the game server normally uses somewhere between 6-8 GB. Usually, around 3-4 GB are free for the block cache.

For some heavy "write to disk" projects we make copy of all data on ram disk, and make hourly snapshots to hdd. don't know is it possible for you or not, but it realy help us.
We also have spikes with large amount of disk writes, but this was from mysql ACID logic.

7) did you defragment xfs with xfs_fsr?

No. I guess I wouldn't mind trying, but I doubt fragmentation is the issue, since it isn't a matter of the filesystem just performing steadily bad, but rather of sudden spikes in I/O latency. This is also part of the reason why I suspect that log flushing is part of the problem. I was hoping that Linux 3.2 would solve some of that since it uses delayed logging in XFS by default, but alas...

You got this spike from large number of write to disk nonseq requests. Why not try to defragment fs?

[loftar]

You got this spike from large number of write to disk nonseq requests. Why not try to defragment fs?

Well, the reason not to would be that the I/O required by defragmentation would make the game even less playable, so I'd have to bring it down while it runs for who knows how many hours, for something which may or may not have any effect. :)

[Mums]

In its current state it is pretty much unplayable, so I do not think anyone would mind.

[stchristopher]

In its current state it is pretty much unplayable, so I do not think anyone would mind.

+1

[Felkin]

In its current state it is pretty much unplayable, so I do not think anyone would mind.

+1

+2

[Robertzon]

You got this spike from large number of write to disk nonseq requests. Why not try to defragment fs?

Well, the reason not to would be that the I/O required by defragmentation would make the game even less playable, so I'd have to bring it down while it runs for who knows how many hours, for something which may or may not have any effect.

There is no effect in playing currently, it's impossible to do anything, take your time and give it a shot, it might fix it.

[Sarchi]

I can play without any problems. Lag is almost unnoticeable.


Ain't even trollin'

[villagegirl]

Hmm, just a thought here, maybe try storing that world 5 data (only keep exactly what you need for this current world) somewhere else. If that's possible, I know money is tight. I was just thinking about how my comp always runs better with more space. Very simple i know im sorry lol, but i just thought i would mention it. Love you guys and thanks for you work!