huge memory usage

[Pavol Klačanský]

Hi, I have got today 1.8 GB usage by kazam, it happend after while.

[David Klasinc (bigwhale)]

Can you provide a little more information on what you were doing in Kazam? Recording a video? Just let it running without recording? If you were recording a video, how long was the video and in which format you were recording. How many audio sources did you include? Does this happen if you record in H264 and VP8?

This will help localize the problem and it will be easier to deal with.

Thanks.

[Pavol Klačanský (pavolzetor-deactivatedaccount)]

I have Version: 1.0.6-0ubuntu1

I was recording video (about 1 minute long), I have used webm (default one)
I had no audio enabled.

I can try h264

[Pavol Klačanský (pavolzetor-deactivatedaccount)]

I have tried both, and I cannot reproduce it, but definitely there must be some memory leak

[Pavol Klačanský (pavolzetor-deactivatedaccount)]

okay, I got it again with h264

[David Klasinc (bigwhale)]

It does seem a lot, but a simple Hello World program written with Gnome Introspection in Python will take up more than 300 MB of RAM on my computer. Kazam itself, when PulseAudio is disabled, will have almost 300MB smaller memory print. Then there's a Gstreamer and all the crap it pulls in.

[Pavol Klačanský (pavolzetor-deactivatedaccount)]

This is not true, I am writing app in python and GI, it uses only about 30 megs (64 bit ubuntu) and it contains not just simple widgets (it is on right side of screenshot). You should recheck your PC.

[David Klasinc (bigwhale)]

Below it is the first hello world program that I googled up. I've attached the screenshot of memory consuption as reported by htop.

#!/usr/bin/env python
from gi.repository import Gtk, Gio
class HelloWorldApp(Gtk.Application):
    def __init__(self):
        Gtk.Application.__init__(self, application_id="apps.test.helloworld",
        flags=Gio.ApplicationFlags.FLAGS_NONE)
        self.connect("activate", self.on_activate)
    def on_activate(self, data=None):
        window = Gtk.Window(type=Gtk.WindowType.TOPLEVEL)
        window.set_title("Gtk3 Python Example")
        window.set_border_width(24)
        label = Gtk.Label("Hello World!")
        window.add(label)
        window.show_all()
        self.add_window(window)
if __name__ == "__main__":
    app = HelloWorldApp()
    app.run(None)

[David Klasinc (bigwhale)]

Also, I left Kazam running for a few minutes (while recording) and checked with System Monitor. Memory column stopped at 86.6MB and didn't increase for a while, when it 'jumped' to 86.7MB and it is still here. At the same time htop was showing 2GB memory usage.

Make what you want from it.

[Pavol Klačanský (pavolzetor-deactivatedaccount)]

in ps it shows for hello world app
pk 2592 0.3 0.5 341556 21836 pts/6 Sl+ 17:28 0:00 python app.py
0.5 * 4 GB == 20 MB

it happens only sometimes with kazam, I have default swappiness, and whne kazam jumped to almost 2 gigs, everything freezed and hard drive was bloody busy.

[David Klasinc (bigwhale)]

I'll keep an eye on this one, but I can't really help right now if there is no way to reproduce this. There's nothing in Kazam's code that could leak this much. :) You could try with new unstable release and use --nosound parameter to exclude PulseAudio. Then if you still hit this bug, you could add --test parameter, to generate a test signal instead of capturing the screen, to eliminate a part of Gstreamer.

For more than that, valgrind or something similar should be used to identify the leak.

[Pavol Klačanský (pavolzetor-deactivatedaccount)]

Thanks, I have installed latest for PPA, but I do not know how to reproduce it, so it just hit be sometimes

[Artiom Neganov (aneganov)]

Well, this also affects me.

Kazam 1.3 (unstable) has just eaten 53% (!) of my 3Gb of RAM (see the attachment) which approx equals to 1500Mib.
This is how it was happening:

1. I had been recording a 3-min video from one of my two displays using H.264 codec.
2. I had stopped the record and saved the file.
3. Watching how my system lagged, I opened `htop` and saw that kazam consumes 53% of RAM (and 0% of CPU). It was just running, not recording.

[Artiom Neganov (aneganov)]

Sorry, I had mistaken - 51.3%, not 53%.

[David Klasinc (bigwhale)]

So, I took some time to do a little testing and write some experimental code. And I did some reading to make sure that I understand the PS output correctly.

First run python and see how much memory it is using:
bigwhale@thefish:~/Code/Kazam/unstable/bin$ python

(open another terminal ...)

bigwhale@thefish:~$ ps aux | grep python | head -1
bigwhale 2264 0.0 0.0 -> 38896 <- -> 5916 <- pts/3 S+ 11:29 0:00 python

The numbers reported are VSZ and RSS. Virtual memory size and resident (not swapped) memory size. Which would mean that python alone is using around 38MB of RAM. In reality this is what python would use if it would be the only running program on the computer. 38MB also includes memory that is shared between other programs.

Next, you can try to load only the certain libraries that Kazam requires to work:

bigwhale@thefish:~/Code/Kazam/unstable/bin$ python
Python 2.7.3 (default, Apr 20 2012, 22:39:59)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
from gi.repository import Gtk, Gdk, GObject, GdkPixbuf
import gst, pygst, cairo, logging, os, multiprocessing, sys
from gettext import gettext as _
from subprocess import Popen
from kazam.pulseaudio.pulseaudio import pulseaudio_q

bigwhale@thefish:~$ ps aux | grep python | head -1
bigwhale 1804 0.0 0.3 -> 417624 <- -> 32084 <- pts/3 Sl+ 10:47 0:00 python

This means that only the imports are more than 400MB of memory. This is before GUI is even initialized. Non shared memory usage that only this python instance is using is ~32MB

Then you can actually import the GUI by pasting the lines below in the python interpreter:

class KazamApp(GObject.GObject):
  def __init__(self):
    GObject.GObject.__init__(self)
    self.builder = Gtk.Builder()
    self.builder.add_from_file("../data/ui/kazam.ui")
    self.builder.connect_signals(self)
    for w in self.builder.get_objects():
      if issubclass(type(w), Gtk.Buildable):
        name = Gtk.Buildable.get_name(w)
        setattr(self, name, w)
  def cb_record_clicked(self):
    pass
  def cb_region_toggled(self):
    pass
  def cb_cursor_switch(self):
    pass
  def cb_timer_switch(self):
    pass
  def cb_codec_changed(self):
    pass
  def cb_volume_changed(self):
    pass
  def cb_volume2_changed(self):
    pass
  def cb_audio_changed(self):
    pass
  def cb_audio2_changed(self):
    pass
  def cb_video_changed(self):
    pass
  def cb_delete_event(self):
    pass

foo = KazamApp()
foo.window.show_all()
Gtk.main()

Checking memory usage again will result in this:
bigwhale@thefish:~$ ps aux | grep python | head -1
bigwhale 2111 0.5 0.4 -> 749844 <- -> 33368 <- pts/3 Sl+ 11:15 0:00 python

It jumped to almost 750MB. And this is before anything actually happens in Kazam and before anything at all was initialized, variables set and so on.

This huge memory usage is mostly shared memory that is already being used if you are using Gnome.

[David Klasinc (bigwhale)]

Also, here's an excellent blog post about memory usage on Linux which will help you understand how memory works:

http://virtualthreads.blogspot.com/2006/02/understanding-memory-usage-on-linux.html

[Pavol Klačanský (pavolzetor-deactivatedaccount)]

so, my memory usage without kazam was about 1.5 GB, and then, after starting it and recording, 1.8 GB + 1 GB in swap (I should disable it or change swappiness, I know). 1.8 + 1 - 1.5 = 1.3 GB for Kazam (if he does share something)

[Artiom Neganov (aneganov)]

@BihWhale

After all those manipulations my result is:

fantomas 6944 0.3 1.0 425240 32004 pts/5 Sl+ 16:26 0:00 python

[Artiom Neganov (aneganov)]

David asked my IRC personification named Onkeltem to post more info about my system.

Well, it's Ubuntu 11.10, x86_64, with medibuntu repo, gnome 3 (gtk 3.2).
As far as I know, I have no custom libraries or codecs installed.

fantomas@alpha:~$ COLUMNS=200 dpkg -l '*gstreamer*' | grep ii
ii gir1.2-gstreamer-0.10 0.10.35-1 Description: GObject introspection data for the GStreamer library
ii gstreamer0.10-ffmpeg 0.10.12-1ubuntu1 FFmpeg plugin for GStreamer
ii gstreamer0.10-fluendo-mp3 0.10.15.debian-1 Fluendo mp3 decoder GStreamer plugin
ii gstreamer0.10-gconf 0.10.30-1ubuntu7.1 GStreamer plugin for getting the sink/source information from GConf
ii gstreamer0.10-gnomevfs 0.10.35-1 GStreamer plugin for GnomeVFS
ii gstreamer0.10-nice 0.1.0-2ubuntu1 ICE library (GStreamer plugin)
ii gstreamer0.10-plugins-bad 0.10.22-2ubuntu4 GStreamer plugins from the "bad" set
ii gstreamer0.10-plugins-base 0.10.35-1 GStreamer plugins from the "base" set
ii gstreamer0.10-plugins-good 0.10.30-1ubuntu7.1 GStreamer plugins from the "good" set
ii gstreamer0.10-plugins-ugly 0.10.18-3ubuntu1 GStreamer plugins from the "ugly" set
ii gstreamer0.10-pulseaudio 0.10.30-1ubuntu7.1 GStreamer plugin for PulseAudio
ii gstreamer0.10-x 0.10.35-1 GStreamer plugins for X11 and Pango
ii libgstreamer-plugins-base0.10-0 0.10.35-1 GStreamer libraries from the "base" set
ii libgstreamer0.10-0 0.10.35-1 Core GStreamer libraries and elements

fantomas@alpha:~$ COLUMNS=200 dpkg -l '*264*' | grep ii
ii libx264-116 2:0.116.2042+git178455c-1ubuntu1 x264 video coding library

[Artiom Neganov (aneganov)]

Better formatted output: http://pastebin.ubuntu.com/950392/

[Brendan_P (brendan-p)]

Hi Folks,

Been hitting this issue regularly. Pretty much every time I try record a screencast it starts hammering the disk (presume it's swap IO) after a couple minutes.

It basically makes this great app useless for me. Be happy to test any updates but be gentle, I'm not a dev.

Cheers
Brendan

[Daniel Novaes Ilha (danielflasher)]

Hi, I have just started using this app today and ran into the same problem.

I was recording my whole screen (1920 x 1080 @ 29 FPS) and after one or two minutes it started running terribly slow, I dropped to tty 1, logged in and ran top. top showed Kazam at first position consuming 120% of my cpu(a dual core Intel i5), 5.7 physical memory and over 9 GB of virtual memory.

Tested again while monitoring it from a terminal and it reaches nearly 2 GB physical and over 4 Gb virtual in seconds both for WebM and h264.

To me it seems the issue is that the recorded data is not stored in disk periodically but rather only once the recording ends, though I haven't checked the source so I'm not sure.

[David Klasinc (bigwhale)]

Thanks for all the additional info. This seems to be a problem with GStreamer, that's the only part of Kazam that is actually using memory. GStreamer is dumping data on the disk as it records. Temporary files are named /tmp/kazam_*. When encoding to h264, there will be one more temporary file created by x264 encoder. After video is saved, temporary files are removed.

I tried many different combinations of codecs, encoders, packages and I wasn't able to reproduce this . I'll keep my eye on this one.

[Joe canti (joe-zwnfzpmic0)]

Hi,

I have a similar issue. I record one channel of audio, h264 and 15fps (also does the same with webM). Everything runs smoothly at the beginning, but at some point it goes slow and the swap file jumps to a couple of gig.

This usually happens after about 10 minutes of recording - at least it's long enough to get some decent screencasts in.

It was happening a lot sooner, but I turned off Cairo Dock as that also runs on Gstreamer(?) - anyway, that greatly improved the situation.

Is there an alternative to Gstreamer? My understanding is that the alternative ffmpeg causes bad video formats?? I can say that when the MP4 is exported and edited, it's great qualoty and very stable.

Thanks, Joe

[Lunarts (lunartsbr-gmail)]

Yup, it basically freeze(too slow) my system at the second recording attempt. I have to shut down the whole computer. I have ubuntu 12.04 mac version on imac 2011 21,5'' amd radeon hd 6770m. recordmydesktop works fine thought.

[Mihai Postelnicu (mpostelnicu)]

Same problem here, i have Ubuntu 12.04 x64 and kazam 1.0.6 'NCC-2893' and gstreamer 0.10.36-1ubuntu0.1

After 5 minutes of screen recording (vp8 or h264, does not matter) the RES memory slowly goes through the roof (>2GB for kazam process) and it obviously almost freezes my laptop with 4gb of RAM. I'm recording 1280x800 with (or without) audio, 15fps.

I have a Radeon Xpress 200 card, and have tried to screencast from both Unity and Gnome classic.

I suspect this has something to do with GStreamer and the method of capture for X11 (x11grab maybe? no idea) that is buggy.

I have noticed the process size does not increase if nothing happens on the screen. If i just keep it idle and watch htop while recording, kazam barely grows in size. If i however switch windows, move the mouse, etc, it starts to grow fast, about 20megs per second...

Obviously gstreamer does something wrong here and does not deallocate the encoded screen captures after encoding them, they linger in the memory, even if they also get written on disk at the same time. I say the encoded screens, because if i sit idle then the compression ratio is obviously bigger and the following captured screens are smaller in size, hence probably why the process stops growing...

Right now kazam is not usable for me, any help would be appreciated

Thanks
Mihai

[Mihai Postelnicu (mpostelnicu)]

x

[David Klasinc (bigwhale)]

Kazam 1.3.2 on Ubuntu 12.10 is now using GStreamer 1.0 for capturing and recording. Can someone try with the latest version if this issue is still present?

[David Klasinc (bigwhale)]

I did some testing at it appears that after recording a seven minutes of 1920x1080 video with VP8 my 8GB of RAM will run out and heavy swapping will commence. It appears that this is a problem with Python implementation of GStreamer. The same pipeline in gst-launch-1.0 will work without any problems.

When I was recording with H264 some memory leakage appeared, but it wasn't noticeable.

I'll test this outside of Gtk and see if the memory leak stays.

[Brendan_P (brendan-p)]

That's good news, thanks for your work on this.

I got 4GB RAM which is probably why I'm more acutely affected (also on
1920x1080)

I'm on 12.04 and don't intending upgrading this machine. Is there a way I
can help testing (and I suppose get backports?)

Cheers
Brendan

On 2 November 2012 12:07, David Klasinc <email address hidden> wrote:

> I did some testing at it appears that after recording a seven minutes of
> 1920x1080 video with VP8 my 8GB of RAM will run out and heavy swapping
> will commence. It appears that this is a problem with Python
> implementation of GStreamer. The same pipeline in gst-launch-1.0 will
> work without any problems.
>
> When I was recording with H264 some memory leakage appeared, but it
> wasn't noticeable.
>
> I'll test this outside of Gtk and see if the memory leak stays.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/981224
>
> Title:
> huge memory usage
>
> Status in Kazam Screencaster:
> Confirmed
>
> Bug description:
> Hi, I have got today 1.8 GB usage by kazam, it happend after while.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kazam/+bug/981224/+subscriptions
>

--
*
----------------------------------------------------------------------------
*
*How to keep in touch:*
W: http://brendanathome.com
G+: http://gplus.to/brendanp

[David Klasinc (bigwhale)]

Somewhat good news. I wrote a short test program to test this and after few tests it showed a big memory leak. However, this is now upstream problem and I can't do much about it unless I start poking and prodding GStreamer/Gtk sources. You can follow the progress on this here:

https://bugzilla.gnome.org/show_bug.cgi?id=687493

I've also raised this on GStreamer devel mailing list. I hope something good comes out of it soon. :)

[eephyne (eephyne)]

I don't know if it can move it forward but :

When i use kazam to record something smaller than 720p (like 1280*680) , it work great (using window or zone) (~ 4% memory usage)
When i use kazam to record the entire desktop (here 1280*1024) , it work great (~ 4% memory usage)
But when i use kazam to record something bigger or equal to 720p , kazam eat my memory very fast (like 20% in 20 seconds and keep growing until the system is unresponsive).

I precise that 720p may be not the limit where it begin to eat memory but this is very close to that ( for me).

Hope this could help

if you need anything don't mint to ask

[Boris Brodski (brodsky-boris)]

Recording video at 964x608, H.264 / AVC, 24 frames with audio on 8GB 64bit Ubuntu start swapping freezing entire system after ~10 minutes. Closing kazam releases all the memory.

Tested with stable 1.0.6 and unstable 1.3.0 version of Kazam.

Linux DellXPS17 3.0.0-28-generic #45-Ubuntu SMP Wed Nov 14 21:57:26 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

PS
Kazam worked for me smoothly for a long time (great thanks for that!).
A Ubuntu security update should have "activated" this bug not more, that a month ago :(

[UbuntuAddicted (ubuntuaddictedubu)]

I too have a memory issue when using Kazam after about 5 to 7 minutes, I am recording a little window of the Shank 2, the window is 1024x576 and it causes the game to lag and even after the recording is over BUT kazam is still open my memory usage is way to high, can't even open google chrome, it gives me the "Jim's Dead" message and that chrome is out of memory. I am using Xubuntu 12.04 64bit version with kazam version 1.0.6-0ubuntu1. I do only have 2GB of RAM and an equal swap partition but this just seems rediculous. Is there a solution?
My kernel is 3.7.0-030700-generic

[Yusuf Ismail Bin Shukor (linkinpark-neon)]

I have the memory leak issue as well.

I'm running Ubuntu 12.10 64bit with 8GB of DDR3. After 2 or 3 minutes, my swap space jumps from 197kb to 1GB. My swap is only 1GB, so when this happens my system freezes up completely. Can't even open tty. Usually have to force shutdown the computer, or sometimes Ubuntu will just restart itself.

I've tried the stable release 1.0.6 and also have been trying all the unstable releases up to 1.3.101, and this issue is still here. It's been haunting me since Ubuntu 12.04.

I've been using recordmydesktop and vokoscreen in the meantime, but Kazam has produced top quality video with synchronised sound for the screencasts where I quickly close it before 1 minute has passed. I really hope this bug can be fixed, as I'd love to use it for recording all my gameplay videos and tutorial videos for Youtube.

I've tested recording just the desktop with no activity on screen and no sound, and this leak still happens. I've tried VP8/WebM, H.264/MP4 and even the RAW/AVI. I've tried using Framerates of 15 up to 60 to see if anything is different, the leak still happens. It happens all the time. On my system it's guaranteed to happen 100% of the time.

Thanks for the effort and taking the time to look into this, I hope Kazam can become a solid stable screen recorder in the future :)

[Yusuf Ismail Bin Shukor (linkinpark-neon)]

I forgot to mention that I'm running at 1920x1080 with an Nvidia GTX 680 on 310.14 drivers, and using the Unity interface. Just posting this in case it's considered important information.

[David Klasinc (bigwhale)]

My production machine is now on Raring, AMD 6850 graphics card with proprietary drivers and 8GB of RAM. I can capture 1080p H.264 videos with less than 10% of memory being used (as reported by htop).

The problem with this leak is that is so unpredictable for me and I can't really pin it down.

I'll add few more debug lines to gather version numbers of all the important packages that are needed for video capture. I hope something good comes out of this.

[Yusuf Ismail Bin Shukor (linkinpark-neon)]

I won't be using Raring until it gets released in April, so I guess I'll have to wait a while before I can try it on there.

I just wanted to add some additional tests I did. I switched off my swap space by going into the terminal and typing "sudo swapoff -a". The memory leak doesn't happen over time. Instead, it happens in one fell swoop. Recording for about a mere 3 minutes with System monitor on to see what happens and from 2.1GB used, to straight shutting down my computer.

The leak was so large my system couldn't handle it without the swap space to fall back on. Tested it twice, exactly the same. This is with 8GB DDR3.

With swap space on, I tried reducing the swappiness to 10 (instead of the usual default 60). Nothing helps. The swap still gets filled to fast and causes my computer to hang.

If there's any sort of scenario you want me to test from the daily unstable builds, I'd be glad to help. I'm on holiday, and am up for helping you out in this regard.

[eephyne (eephyne)]

To all who have issue, did you try to reccord a smallest size to see if that change something (like me, cf my comment) ? , if this is the same for everyone , this could be a lead, no ?

[Alin Andrei (nilarimogard)]

In my test under Ubuntu Raring, the leak only happens when recording in mp4. It doesn't occur for webm.

[David Klasinc (bigwhale)]

This is getting really frustrating. Today I recorded 21 minutes of footage in H264. Latest Ubuntu Raring, GStreamer 1.0.5. 1080p at 15fps. AMD HD6850 with fglrx 9.012-0ubuntu1~xedgers~raring1

Some normal desktop usage and then I fired up Steam and launched Warzone: European Escallation and played it for about 15 minutes. I was also capturing sound. Memory usage on my 8GB machine didn't grow past 9% which should be acceptable.

I was hoping this was VP8 and/or Nvidia problem. for VP8 I am sure that it is leaking a lot, but H264 should be better.

[David Klasinc (bigwhale)]

Recent development confirmed big memory leak with VP8. There is a choice between memory leak and smooth screencast or no memory leak and choppy and useless video.

This is a relevant link in the Gnome bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=687493

[Arnau (ninjastyleftw)]

I'm having this problem on Raring too, I'm getting too frustrated because I really need to do screencasting u_u

[Arnau (ninjastyleftw)]

Today I recorded 4 minutes of Minecraft and Kazam was using 2 Gb of my Shared Memory, so I'm having this memory leak using MP4 and not VP8, so where's the problem in this case?

[Yusuf Ismail Bin Shukor (linkinpark-neon)]

Sadly, this problem still persists with Kazam 1.4.4 in Ubuntu 14.04 64bit [fresh install]. Just tried to record some Sims 3 gameplay, and once more after several minutes Kazam will start to rampage all available memory. I have since changed from an AMD motherboard and CPU to an Intel motherboard and CPU, yet this still plagues me. H.264 with the MP4 container.

System specs:
OS: Ubuntu 14.04 64bit Trusty Tahr
CPU: i7-4770 3.4GHz
GPU: Nvidia GTX 680 (Proprietary 337.12)
RAM: 8GB DDR3 1333MHz
DE: Unity 7