View Issue Details

IDProjectCategoryView StatusLast Update
0000004LDMud 3.2-devOtherpublic2004-05-17 09:27
Reportermenaures Assigned Tolars 
PrioritynormalSeveritymajorReproducibilityN/A
Status closedResolutionfixed 
Summary0000004: Driver eats CPU
DescriptionAfter >100 days uptime in dev540 (heh, good one) UNItopia crashed and switched to dev585.

This new driver seems to be a lot more CPU intensive than dev540. Currently, there are about 90 users logged in and the driver requires about 70% average (between 50%-90%) CPU. Back with the old driver, I remember values about 20-30% with 50% max.

I'm not quite 100% sure that this is a driver issue. I'm reporting this because I heard people from other MUDs complain about higher CPU usage, too, which makes me think that this is likely to be a driver issue.

I think I'll play around with different driver versions now and report if I actually find anything.
TagsNo tags attached.

Activities

dafire

2003-06-02 04:19

reporter   ~0000003

I guess it's an driver issue because alwin@avalon reported the same issue in the mailing list

menaures

2003-06-03 12:25

reporter   ~0000004

Currently I don't have any idea on how to 100% reproduce this in a homemud. What I did, is compile drivers in all versions from dev540-dev585, start one after another with the same task and measure the time the driver requires to fulfill this task.

There's just one significant sign I could find:

GNU time for dev540-dev574 is similar to:
22.73user 0.43system 3:27.23elapsed 11%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (332major+1501minor)pagefaults 0swaps

GNU time for dev575-585 is similar to:
22.85user 0.35system 3:27.23elapsed 11%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (329major+4098minor)pagefaults 0swaps

That minor value is about 1500 in dev540-dev574, and about 4000 in dev575-dev585. No, I don't know if this does mean anything...

menaures

2003-07-10 20:17

reporter   ~0000007

still got similar problems in dev570. May be some object(s) in the mud, though object-dump eval statistics dont show anything too unusual. I need some debugging approach, is there some way to find out what the driver is doing with all the CPU power he consumes?

lars

2003-07-24 01:08

reporter   ~0000008

This is what Alwin mailed me today (so I can have it all in one place):

------------------
Der letzte Driver den wir hatten - mit dem es lief - war 3.2.10dev543. wir wollten auf dev586 wechseln nach unseren 100tagen uptime aber das war schlicht nicht moeglich. mit dem jetztigen geht es halbwegs. der 586 stand bei 90% bis 99% cpu permanent bei hinreichend anzahl spieler.

Da die CPU Last wirklich proportional zur Anzahl der Spieler ansteigt... *gruebel* nee. keine Prognose. Dafuer kenne ich den driver - source zu wenig :) Es lässt sich auch schlecht im Homemud nach vollziehen - ich bekomme schlicht die nötige anzahl aktiver spieler nicht zusammen - richtig spürbar wirds ab ca. 20. achso: wenn die spieler statuen sind, dh., verbindung gekappt is die welt auch in ordnung. d.h., an unseren massen NPCs kanns auch nicht liegen - die machen ihren kram ja in der zeit weiter. Aber es gibt halt keine Interaktion der Spieler mehr.
Menaures@uni hatte doch auch von einem ähnlichen problem berichtet *grübel* Hast du am select fuer die tcp-sockets was geändert? Ich würde vermutlich als erstes da suchen, d.h., in der Kommunikation.

Achja. und da ein zurueck zum alten driver ja dazu führt, dass die Belastung verschwindet, glaube ich auch ernsthaft nicht an ein Problem mit unserer Mudlib...
------------------

lars

2003-07-28 22:10

reporter   ~0000009

The problem was in the change in the mapping compaction: as mappings were no longer compacted unconditionally, each call to compact_mappings() considered many more mappings that it compacted. Unfortunately, the considered mappings did not count against the numerical limit passed to compact_mappings(), so the function walked the whole list on every call. Worse, each considered mapping was checked for destructed objects every time around, wasting lots of CPU unnecessarily.

Issue History

Date Modified Username Field Change
2003-06-01 13:31 menaures New Issue
2003-06-02 04:19 dafire Note Added: 0000003
2003-06-03 12:25 menaures Note Added: 0000004
2003-07-10 20:17 menaures Note Added: 0000007
2003-07-24 01:08 lars Note Added: 0000008
2003-07-24 02:09 lars Status new => assigned
2003-07-24 02:09 lars Assigned To => lars
2003-07-28 22:10 lars Status assigned => resolved
2003-07-28 22:10 lars Resolution open => fixed
2003-07-28 22:10 lars Note Added: 0000009
2004-05-17 09:27 lars Status resolved => closed