View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000004 | LDMud 3.2-dev | Other | public | 2003-06-01 11:31 | 2004-05-17 07:27 |
| Reporter | menaures | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Summary | 0000004: Driver eats CPU | ||||
| Description | After >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. | ||||
| Tags | No tags attached. | ||||
|
|
I guess it's an driver issue because alwin@avalon reported the same issue in the mailing list |
|
|
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... |
|
|
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? |
|
|
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... ------------------ |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-06-01 11:31 | menaures | New Issue | |
| 2003-06-02 02:19 | dafire | Note Added: 0000003 | |
| 2003-06-03 10:25 | menaures | Note Added: 0000004 | |
| 2003-07-10 18:17 | menaures | Note Added: 0000007 | |
| 2003-07-23 23:08 |
|
Note Added: 0000008 | |
| 2003-07-24 00:09 |
|
Status | new => assigned |
| 2003-07-24 00:09 |
|
Assigned To | => lars |
| 2003-07-28 20:10 |
|
Status | assigned => resolved |
| 2003-07-28 20:10 |
|
Resolution | open => fixed |
| 2003-07-28 20:10 |
|
Note Added: 0000009 | |
| 2004-05-17 07:27 |
|
Status | resolved => closed |
