[Resolved] Performance troubleshooting

Posted on by einar.hjortdal

This topic has 9 replies, 2 voices, and was last updated 2 days, 7 hours ago by einar.hjortdal.

Viewing 3 reply threads

Author

Posts
- February 14, 2025 at 11:29 am #29301
  
  einar.hjortdal
  Participant
  
  When I begun my journey with openmamba I experienced very slow performance, I suspected it was exclusively due to the nuoveau driver not working right.
  
  The nvidia-470 package was then fixed and it seems to be running correctly on my system right now.
  
  Unfortunately, while the nvidia-470 did improve performance significantly, I am still experiencing very poor performance. And I am not sure what is causing it.
  
  I have looked at logs using KSystemLog: there does not appear to be any error+ level entries besides Failed to start colord.service. and [drm:drm_new_set_master [drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to grab modeset ownership. I do not believe the nvidia error is problematic, a google search suggests it is nothing to worry about.
  
  I develop web applications using VSCode and Edge. Starting VSCode takes minutes. Dragging tabs in Edge freezes the interface for a few seconds and animations are all bugging out as if the system could not render them. I need to work on some animations for a web frontend and the lag & bugginess is making it impossible.
  
  I am not sure how to figure out why I am experiencing this bad performance. I have verified that the issue is limited to openmamba as I don’t experience this in Windows and on a Fedora live cd. Please, give me directions on how to figure out the source of the problem.
- February 14, 2025 at 4:00 pm #29302
  
  einar.hjortdal
  Participant
  
  I have noticed that this issue seems to go mostly away after waking up the system from sleep, and logging back in with sddm.
- February 15, 2025 at 2:24 pm #29304
  
  Silvan
  Keymaster
  
  The described symptoms of low preformances are related to VSCode and Edge. According to a former report VSCode is manually installed in user home and the report showed a lot of processes running.
  
  In order to be able to help troubleshooting bad performances in openmamba installation itself it is adviced to report the issue when no custom software is installed and running, i.e. no scripts and processes from third party software or else recognize that the performance throubleshooting help requested is related to running custom installed VSCode and Edge. Additionally, openmamba provides VSCode with the package visual-studio-code-bin which I frequently use for software development.
  
  General comments follow.
  When observing slow performance with an openmamba component, i.e. extracting a tar archive as written in former report, the operation can be monitored for CPU and and I/O usage. If it is a CPU performance problem, tools would report 100% usage of one or more cores. A tool like cpupower-gui might help to check and set the CPU usage for appropriate performances in terms of clock frequency. When I/O is causing slowness, different things might be checked which I’m skipping here. When no system log errors are show, CPU and I/O usage are reported as idle while uncompressing but the user sees slowness it would be the kernel that is not working correctly. openmamba uses the LTS 6.6 kernel, if the hardware is recent it might be better supported by more recent kernel. This (which kernel version when it works better) can be cross-checked since you have reported a list of other Linux distribution where you don’t have the issue.
  - February 18, 2025 at 9:25 am #29305
    einar.hjortdal
    Participant
    In order to be able to help troubleshooting bad performances in openmamba installation itself it is adviced to report the issue when no custom software is installed and running
    
    I would like to clarify: the issue shows even without user-installed VSCode and/or Microsoft Edge.
    
    The slowdown can be clearly experienced with Dolphin and KSystemLog, for example.
    
    It is however very obvious when VSCode and Edge are running because they’re more complex programs that use more system resources than anything else my openmamba installation has, as far as I know.
    
    openmamba uses the LTS 6.6 kernel, if the hardware is recent it might be better supported by more recent kernel
    
    The hardware is relatively old: intel i7 4790K and nvidia gtx 780, I do not believe kernel support is the issue.
    
    So far I can consistently replicate the disappearance of the issue after one single sleep/wake cycle. Something clearly happens with that, but I don’t know what.
    
    Every time I boot openmamba, I immediately put the system to sleep and wake it up, this resolves the issue until the next reboot.
    
    Given that sleep/wake reliably solves the issue, do you have any guess for what to investigate?
    
    A tool like cpupower-gui might help to check and set the CPU usage for appropriate performances in terms of clock frequency. When I/O is causing slowness, different things might be checked which I’m skipping here. When no system log errors are show, CPU and I/O usage are reported as idle while uncompressing but the user sees slowness it would be the kernel that is not working correctly.
    
    I can verify if cpupower-gui shows anything before/after a sleep/wake cycle.
    
    This reply was modified 4 days, 7 hours ago by einar.hjortdal.
- February 18, 2025 at 10:30 am #29307
  
  Silvan
  Keymaster
  
  You may want to try to remove the cpupower-gui package which is currently the only guess about CPU frequency improperly set.
  For further investigations from this side you may also want to send two reports: one after boot when the system is slow and another after a sleep/resume cycle.
  - February 18, 2025 at 10:45 am #29308
    
    einar.hjortdal
    Participant
    
    Actually, I think cpupower-gui showed a lot! Thanks for the suggestion.
    
    After a boot, cpupower-gui shows each core is stuck at 800Mhz, after a sleep/wake it behaves as expected and boosts up to 4Ghz when needed.
    - February 19, 2025 at 9:25 am #29309
      
      einar.hjortdal
      Participant
      
      Today after a system update and a clean boot, the problem was not replicable any longer. Maybe a patch fixed it?
    - February 19, 2025 at 8:06 pm #29310
      Silvan
      Keymaster
      
      Nothing was specifically patched. Generally speaking the only relevant update might be the kernel update but if you update daily it was not in today updates.
      
      I find it more likely that by running cpupower-gui you fixed its behaviour at startup, because in the old report there was this in the logs:
      
      cpupower-gui[5372]: Applying configuration... systemd[5330]: cpupower-gui-user.service: Main process exited, code=exited, status=255/EXCEPTION systemd[5330]: cpupower-gui-user.service: Failed with result 'exit-code'. systemd[5330]: Failed to start cpupower-gui-user.service.
      
      These considerations are based on and limited by the information I have.
    - February 20, 2025 at 9:19 am #29311
      
      einar.hjortdal
      Participant
      
      I’ll try to be as precise as possible regarding what I did then. When you suggested to check the CPU frequency with cpupower-gui I did the following:
      
      1) fresh boot of openmamba. run cpupower-gui and noticed CPU being stuck at 800Mhz on all threads.
      
      2) sleep/wake the system. cpupower-gui shows CPU clock boosting correctly. Now I did update and a kernel update was included in the update. This doesn’t do good to isolating causes, I agree.
      
      3) rebooted. run cpupower-gui and noticed CPU boosting correctly.
      
      I was not aware that there is a cpupower-gui-user service. I do not know cpupower at all, I thought it was just a utility to show CPU behavior, I do not know if it actually does act on the CPU behavior.
      
      All I can say besides that is that this issue appeared in every installation of openmamba I have done on this system. I hope it’s gone for good on this installation!
Author

Posts

Viewing 3 reply threads

You must be logged in to reply to this topic.