Mailing List Archive: MythTV: Users

64 Bit and memory

1 2

View All

Index | Next | Previous | View Threaded

mitchell.gore at gmail

Jan 7, 2008, 10:03 AM

Post #1 of 26 (1620 views)
Permalink

64 Bit and memory

Hi,

i have built my first 64 bit Mythbox on a AMD X2 5200. I put a gig of DDR2
800 in the box assuming that would be enough.

The machine doesn't seem to be as 'snappy' as I was hoping. I know 64bit
uses more memory that 32bit but I figured 1 gig is enough, as a used to run
the same be/fe on 512mb. Do I really more than a gig to reach top
performance of 64bit?

When I built the box out I just assumed I should use x86-64 being that is
what the process is. I am really not looking forward to rebuilding the box
in 32bit. If I can just purchase another gig of memory and fix it that
would be preferred.

Thoughts?

Thanks,
Mitchell

myth at dermanouelian

Jan 7, 2008, 10:08 AM

Post #2 of 26 (1585 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Jan 7, 2008, at 10:03 AM, Mitch Gore wrote:

> Hi,
>
> i have built my first 64 bit Mythbox on a AMD X2 5200. I put a gig
> of DDR2 800 in the box assuming that would be enough.
> The machine doesn't seem to be as 'snappy' as I was hoping. I know
> 64bit uses more memory that 32bit but I figured 1 gig is enough, as
> a used to run the same be/fe on 512mb. Do I really more than a gig
> to reach top performance of 64bit?
>
Does top tell you it's running out of memory? If so, add more.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

drescherjm at gmail

Jan 7, 2008, 10:16 AM

Post #3 of 26 (1579 views)
Permalink

Re: 64 Bit and memory [In reply to]

> The machine doesn't seem to be as 'snappy' as I was hoping. I know 64bit
> uses more memory that 32bit but I figured 1 gig is enough, as a used to run
> the same be/fe on 512mb. Do I really more than a gig to reach top
> performance of 64bit?
>
No you do not need 1GB. Also the difference in memory need from 32 to
64 bit is minimal because only the pointers default to 64 bit.

John
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

mitchell.gore at gmail

Jan 7, 2008, 11:09 AM

Post #4 of 26 (1556 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Jan 7, 2008 12:16 PM, John Drescher <drescherjm [at] gmail> wrote:

> > The machine doesn't seem to be as 'snappy' as I was hoping. I know
> 64bit
> > uses more memory that 32bit but I figured 1 gig is enough, as a used to
> run
> > the same be/fe on 512mb. Do I really more than a gig to reach top
> > performance of 64bit?
> >
> No you do not need 1GB. Also the difference in memory need from 32 to
> 64 bit is minimal because only the pointers default to 64 bit.
>
> John
>
>

So i need to figure out why i am using so much memory. When looking at htop
is see 418mb/939mb for RAM (Onboard video so i dont see a gig)
0/2500mb for SWAP.

This is after a fresh reboot. Here is what is running:
I have a dual desktop one 1080p and the other is 1024x768 both running
GNOME.
Azureus/java
mythbackend +dependencies
all fedora 8 stuff.

Looking at htop and sorting by Mem% doesnt really help as to what is uses
memory/how much. Is there a better way?

This is wierd as my FE running F7 x86 uses 32mb of ram on boot. Granted its
running fluxbox and no backend up 400mb for the backend and GNOME seems
crazy.

Thanks,
Mitchell

nico at youplala

Jan 7, 2008, 11:29 AM

Post #5 of 26 (1561 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Mon, 2008-01-07 at 12:03 -0600, Mitch Gore wrote:
> The machine doesn't seem to be as 'snappy' as I was hoping. I know
> 64bit uses more memory that 32bit but I figured 1 gig is enough, as a
> used to run the same be/fe on 512mb. Do I really more than a gig to
> reach top performance of 64bit?

I'm happy with my 64-bit system with "only" 1 GB of RAM, playing 1080p
content and all.

Linux is good at using 100% of the RAM, mostly for caching (called
buffers in top and free). Are you sure this is not the situation on your
system?

My quick test of Vista MCE certainly was unhappy in "only" 1 GB. Yeah
for Open Source!

Nico
http://www.youplala.net/linux/home-theater-pc

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

nico at youplala

Jan 7, 2008, 11:32 AM

Post #6 of 26 (1558 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Mon, 2008-01-07 at 13:09 -0600, Mitch Gore wrote:
> So i need to figure out why i am using so much memory. When looking
> at htop is see 418mb/939mb for RAM (Onboard video so i dont see a gig)
> 0/2500mb for SWAP.

Not swapping, not running out of RAM....

> This is after a fresh reboot. Here is what is running: I have a
> dual desktop one 1080p and the other is 1024x768 both running GNOME.

Desktops eat RAM.

> Azureus/java

Java VMs eat RAM like there is no tomorrow.

> mythbackend +dependencies all fedora 8 stuff.

Nico

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

drescherjm at gmail

Jan 7, 2008, 11:32 AM

Post #7 of 26 (1563 views)
Permalink

Re: 64 Bit and memory [In reply to]

> So i need to figure out why i am using so much memory. When looking at htop
> is see 418mb/939mb for RAM (Onboard video so i dont see a gig)
> 0/2500mb for SWAP.
>
> This is after a fresh reboot. Here is what is running:
> I have a dual desktop one 1080p and the other is 1024x768 both running
> GNOME.
> Azureus/java
> mythbackend +dependencies
> all fedora 8 stuff.
>
Use the free -m command instead as this will tell you how much of this is cache.

John
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

mitchell.gore at gmail

Jan 7, 2008, 11:57 AM

Post #8 of 26 (1562 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Jan 7, 2008 1:32 PM, Nicolas Will <nico [at] youplala> wrote:

>
> On Mon, 2008-01-07 at 13:09 -0600, Mitch Gore wrote:
> > So i need to figure out why i am using so much memory. When looking
> > at htop is see 418mb/939mb for RAM (Onboard video so i dont see a gig)
> > 0/2500mb for SWAP.
>
> Not swapping, not running out of RAM....
>
> > This is after a fresh reboot. Here is what is running: I have a
> > dual desktop one 1080p and the other is 1024x768 both running GNOME.
>
> Desktops eat RAM.
>
>
> > Azureus/java
>
> Java VMs eat RAM like there is no tomorrow.
>
>
> > mythbackend +dependencies all fedora 8 stuff.
>
>
> Nico
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>

[myth [at] mytht ~]$ free -m
total used free shared buffers cached
Mem: 939 707 232 0 67 213
-/+ buffers/cache: 426 513
Swap: 2596 0 2596

so am i ok?

The reason am asking as i believe the SVN i compiled was having a memory
leak. As when the frontend was running my free RAM slowly disappeared. I
have since removed that version and installed Axels bleeding packages. I
have yet to test these new packages yet. I will tonight and let everyone
know.

I just wanted to make sure i didnt have a system level issue.

Thanks,
mitchell

drescherjm at gmail

Jan 7, 2008, 12:14 PM

Post #9 of 26 (1557 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Jan 7, 2008 2:57 PM, Mitch Gore <mitchell.gore [at] gmail> wrote:
>
> On Jan 7, 2008 1:32 PM, Nicolas Will <nico [at] youplala> wrote:
>
> >
> >
> > On Mon, 2008-01-07 at 13:09 -0600, Mitch Gore wrote:
> > > So i need to figure out why i am using so much memory. When looking
> > > at htop is see 418mb/939mb for RAM (Onboard video so i dont see a gig)
> > > 0/2500mb for SWAP.
> >
> > Not swapping, not running out of RAM....
> >
> >
> > > This is after a fresh reboot. Here is what is running: I have a
> > > dual desktop one 1080p and the other is 1024x768 both running GNOME.
> >
> > Desktops eat RAM.
> >
> >
> > > Azureus/java
> >
> > Java VMs eat RAM like there is no tomorrow.
> >
> >
> >
> > > mythbackend +dependencies all fedora 8 stuff.
> >
> >
> > Nico
> >
> >
> >
> >
> > _______________________________________________
> > mythtv-users mailing list
> > mythtv-users [at] mythtv
> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
> >
>
>
> [myth [at] mytht ~]$ free -m
> total used free shared buffers cached
> Mem: 939 707 232 0 67 213
> -/+ buffers/cache: 426 513
> Swap: 2596 0 2596
>
> so am i ok?
>
This means you have 462MB used and 513 free. See here:

http://gentoo-wiki.com/FAQ_Linux_Memory_Management

John
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

nico at youplala

Jan 7, 2008, 12:25 PM

Post #10 of 26 (1551 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Mon, 2008-01-07 at 13:57 -0600, Mitch Gore wrote:
> [myth [at] mytht ~]$ free -m
> total used free shared buffers
> cached
> Mem: 939 707 232 0 67
> 213
> -/+ buffers/cache: 426 513
> Swap: 2596 0 2596
>
> so am i ok?

Yes, 213 MB of your free RAM is used as cache in an attempt to speed
things up.

Nico

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

mitchell.gore at gmail

Jan 7, 2008, 7:36 PM

Post #11 of 26 (1536 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Jan 7, 2008 2:25 PM, Nicolas Will <nico [at] youplala> wrote:

>
> On Mon, 2008-01-07 at 13:57 -0600, Mitch Gore wrote:
> > [myth [at] mytht ~]$ free -m
> > total used free shared buffers
> > cached
> > Mem: 939 707 232 0 67
> > 213
> > -/+ buffers/cache: 426 513
> > Swap: 2596 0 2596
> >
> > so am i ok?
>
> Yes, 213 MB of your free RAM is used as cache in an attempt to speed
> things up.
>
> Nico
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>

So the bleeding packages didnt really fix anything. When i was watching
HDTV and a commflag was going on i see this with free -m

[myth [at] mytht ~]$ free -m
total used free shared buffers cached
Mem: 939 930 8 0 1 88
-/+ buffers/cache: 840 98
Swap: 2596 1069 1527
[myth [at] mytht ~]$

So ram is full and a gig of swap is being used! The system really
drags..... I just upgraded this box and was expecting stuff like this to
fly when I have a 2.4ghz dual core! Is this just how it is?

Mitchell

esejr at wildroseinternet

Jan 7, 2008, 9:18 PM

Post #12 of 26 (1531 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Mon, 7 Jan 2008 21:36:19 -0600, "Mitch Gore" <mitchell.gore [at] gmail>
wrote:
> On Jan 7, 2008 2:25 PM, Nicolas Will <nico [at] youplala> wrote:
>
>>
>> On Mon, 2008-01-07 at 13:57 -0600, Mitch Gore wrote:
>> > [myth [at] mytht ~]$ free -m
>> > total used free shared buffers
>> > cached
>> > Mem: 939 707 232 0 67
>> > 213
>> > -/+ buffers/cache: 426 513
>> > Swap: 2596 0 2596
>> >
>> > so am i ok?
>>
>> Yes, 213 MB of your free RAM is used as cache in an attempt to speed
>> things up.
>>
>> Nico
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users [at] mythtv
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>>
>
>
>
> So the bleeding packages didnt really fix anything. When i was watching
> HDTV and a commflag was going on i see this with free -m
>
> [myth [at] mytht ~]$ free -m
> total used free shared buffers cached
> Mem: 939 930 8 0 1 88
> -/+ buffers/cache: 840 98
> Swap: 2596 1069 1527
> [myth [at] mytht ~]$
>
> So ram is full and a gig of swap is being used! The system really
> drags..... I just upgraded this box and was expecting stuff like this to
> fly when I have a 2.4ghz dual core! Is this just how it is?
>
> Mitchell

Mitchell,
I also run the SVN on FC7, I've been having this memory leak issue for the
past month or so, you're not alone in it. So far I have been unsuccessful
at finding the cause. After about 16 hours or so it brings my (very
similar) system down, and I have to reboot. As a workaround I have been
exiting the frontend each time I use it and loading up only when I need to.
At least that way my recordings keep going. I was thinking of putting in a
bug report, but I've never done it before and I honestly don't have any
information that would help the devs track this problem down.

Erik

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

drayson at net1plus

Jan 10, 2008, 5:38 AM

Post #13 of 26 (1505 views)
Permalink

Re: 64 Bit and memory [In reply to]

> -----Original Message-----
> From: mythtv-users-bounces [at] mythtv [mailto:mythtv-users-
> bounces [at] mythtv] On Behalf Of Erik Sejr
> Sent: Tuesday, January 08, 2008 12:19 AM
> To: Discussion about mythtv
> Subject: Re: [mythtv-users] 64 Bit and memory
>
>
>
> On Mon, 7 Jan 2008 21:36:19 -0600, "Mitch Gore"
> <mitchell.gore [at] gmail>
> wrote:
> > On Jan 7, 2008 2:25 PM, Nicolas Will <nico [at] youplala> wrote:
> >
> >>
> >> On Mon, 2008-01-07 at 13:57 -0600, Mitch Gore wrote:
> >> > [myth [at] mytht ~]$ free -m
> >> > total used free shared buffers
> >> > cached
> >> > Mem: 939 707 232 0 67
> >> > 213
> >> > -/+ buffers/cache: 426 513
> >> > Swap: 2596 0 2596
> >> >
> >> > so am i ok?
> >>
> >> Yes, 213 MB of your free RAM is used as cache in an attempt to speed
> >> things up.
> >>
> >> Nico
> >>
> >> _______________________________________________
> >> mythtv-users mailing list
> >> mythtv-users [at] mythtv
> >> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
> >>
> >
> >
> >
> > So the bleeding packages didnt really fix anything. When i was
> watching
> > HDTV and a commflag was going on i see this with free -m
> >
> > [myth [at] mytht ~]$ free -m
> > total used free shared buffers
> cached
> > Mem: 939 930 8 0 1
> 88
> > -/+ buffers/cache: 840 98
> > Swap: 2596 1069 1527
> > [myth [at] mytht ~]$
> >
> > So ram is full and a gig of swap is being used! The system really
> > drags..... I just upgraded this box and was expecting stuff like
> this to
> > fly when I have a 2.4ghz dual core! Is this just how it is?
> >
> > Mitchell
>
> Mitchell,
> I also run the SVN on FC7, I've been having this memory leak issue for
> the
> past month or so, you're not alone in it. So far I have been
> unsuccessful
> at finding the cause. After about 16 hours or so it brings my (very
> similar) system down, and I have to reboot. As a workaround I have been
> exiting the frontend each time I use it and loading up only when I need
> to.
> At least that way my recordings keep going. I was thinking of putting
> in a
> bug report, but I've never done it before and I honestly don't have any
> information that would help the devs track this problem down.
>
> Erik
>

I'm running a SVN(15354) frontend/backend on Gentoo with 32 bits and I'm not
seeing this problem.
asgard ~ # free -m
total used free shared buffers cached
Mem: 503 486 16 0 92 67
-/+ buffers/cache: 326 176
Swap: 1961 0 1960

I do however need another 512 on the frontend system :P

My backend only system which is 64 bit same SVN build and flavor of linux
does not have the issue either.
niflheim ~ # free -m
total used free shared buffers cached
Mem: 941 455 485 0 132 178
-/+ buffers/cache: 145 795
Swap: 1961 0 1960

So if anything this might be a frontend specific bug.

Marc

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

r-mythtv at thefreemanclan

Jan 10, 2008, 6:23 AM

Post #14 of 26 (1500 views)
Permalink

Re: 64 Bit and memory [In reply to]

Marc wrote:
> I'm running a SVN(15354) frontend/backend on Gentoo with 32 bits and I'm not
> seeing this problem.
> asgard ~ # free -m
> snip...

I just noticed these posts. If you're concerned about memory leaks /
etc looking at the output of free is just about useless. Look at how
much memory individual processes are taking up instead.

It is completely normal for a linux system with 500GB of memory and at
least as much hard drive space to swap to disk, and report most of the
memory as in use just about all the time.

The reason memory seems to be always in-use is that "free" memory in
linux is memory that is not being used AT ALL for any purpose. Linux
tries to minimize the amount of completely-unused memory - preferring to
use it for buffering or cache. When the memory is needed the cache is
purged and the buffers are flushed. This only improves system
performance by reducing disk access. If memory isn't needed for
something else you might as well use it as cache - it doesn't cost
anything as cache can be instantly purged to be made available.

The reason swapping happens all the time on linux is because of the
"swapiness" setting. If a page of memory seems to be idle for a very
long time the system will swap it out when it is otherwise not busy to
make more room for cache/buffers. The assumption is that something else
will need that memory before the idle app does, or that caching will
generally improve performance. So even if there is free memory the
system will swap out empty pages. This behavior can be tuned with a
setting in /proc if necessary.

A memory leak is when an application allocates memory and then doesn't
use it, or stops using memory but doesn't free it. It causes an
application's virtual memory use to grow, but its real memory use does
not necessarily grow as much (because of the aforementioned swappiness -
linux just swaps the dead pages out to disk and never reads them back).
The ability to swap dead pages would probably depend on whether the
wasted memory fills entire pages - it still isn't ideal.

I haven't observed memory leaks on my 64bit gentoo system, or on my
32-bit frontend (with about 200MB available RAM and no swap). I have
increased my buffer sizes on my backend, so that can consume a fair
amount of virtual memory - but nothing really more than expected.

When my myth system is slow I've found that the usual cause is IO
contention. Swapping contributes to this in part, but only in part.
The iostat tool can help troubleshoot this. The ionice tool can help
mitigate this. I run the backend with a medium realtime ioniceness
setting - this allows the backend access to the disk just about anytime
it needs it without waiting in line. That and increasing my buffers
and getting rid of the buffer fsync have completely eliminated by
IOBOUND issues.

In any case, the way to spot a memory leak is looking at the output of
top or ps -o args,vsz,rss -u mythtv (or whatever). Sorting top by
memory use is a good way to find out where all your RAM is going. You
might be surprised to find out that it is something else entirely.

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

mitchell.gore at gmail

Jan 10, 2008, 7:43 PM

Post #15 of 26 (1493 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Jan 10, 2008 8:23 AM, Richard Freeman <r-mythtv [at] thefreemanclan>
wrote:

> Marc wrote:
> > I'm running a SVN(15354) frontend/backend on Gentoo with 32 bits and I'm
> not
> > seeing this problem.
> > asgard ~ # free -m
> > snip...
>
> I just noticed these posts. If you're concerned about memory leaks /
> etc looking at the output of free is just about useless. Look at how
> much memory individual processes are taking up instead.
>
> It is completely normal for a linux system with 500GB of memory and at
> least as much hard drive space to swap to disk, and report most of the
> memory as in use just about all the time.
>
> The reason memory seems to be always in-use is that "free" memory in
> linux is memory that is not being used AT ALL for any purpose. Linux
> tries to minimize the amount of completely-unused memory - preferring to
> use it for buffering or cache. When the memory is needed the cache is
> purged and the buffers are flushed. This only improves system
> performance by reducing disk access. If memory isn't needed for
> something else you might as well use it as cache - it doesn't cost
> anything as cache can be instantly purged to be made available.
>
> The reason swapping happens all the time on linux is because of the
> "swapiness" setting. If a page of memory seems to be idle for a very
> long time the system will swap it out when it is otherwise not busy to
> make more room for cache/buffers. The assumption is that something else
> will need that memory before the idle app does, or that caching will
> generally improve performance. So even if there is free memory the
> system will swap out empty pages. This behavior can be tuned with a
> setting in /proc if necessary.
>
> A memory leak is when an application allocates memory and then doesn't
> use it, or stops using memory but doesn't free it. It causes an
> application's virtual memory use to grow, but its real memory use does
> not necessarily grow as much (because of the aforementioned swappiness -
> linux just swaps the dead pages out to disk and never reads them back).
> The ability to swap dead pages would probably depend on whether the
> wasted memory fills entire pages - it still isn't ideal.
>
> I haven't observed memory leaks on my 64bit gentoo system, or on my
> 32-bit frontend (with about 200MB available RAM and no swap). I have
> increased my buffer sizes on my backend, so that can consume a fair
> amount of virtual memory - but nothing really more than expected.
>
> When my myth system is slow I've found that the usual cause is IO
> contention. Swapping contributes to this in part, but only in part.
> The iostat tool can help troubleshoot this. The ionice tool can help
> mitigate this. I run the backend with a medium realtime ioniceness
> setting - this allows the backend access to the disk just about anytime
> it needs it without waiting in line. That and increasing my buffers
> and getting rid of the buffer fsync have completely eliminated by
> IOBOUND issues.
>
> In any case, the way to spot a memory leak is looking at the output of
> top or ps -o args,vsz,rss -u mythtv (or whatever). Sorting top by
> memory use is a good way to find out where all your RAM is going. You
> might be surprised to find out that it is something else entirely.
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>

I understand how linux does its memory usage and what not. But i am not
talking about using alot of my memory and it being 'slower'. When I say
slow the mouse wont even move fluidly. It jumps 1/2 way across the screen
as i move it. I look at htop and see mem usage is 100% and swap is
1000/2500m used. The usage of swap increases the longer I leave the
frontend open. Looking at memory to processes correlation I see the
mythfrontend processes each taking 9.4% of memory. And when there are 15
processes going for mythfrontend it eats everything up. When I killall
mythfrontend the problem gets better. I can atleast run the frontend with
some experience but the only way to really get a fast userspace is to
reboot.

Again I am using atrpms bleeding packages which are SVN r15333. I believe
this my be a x86-64 issue. As my 32bit works fine with the same packages.
both are F8 fully updated boxes.

How do i got about figuring out where the issue is? I am not the only one
seeing this problem and its a SERIOUS one!

If a Dev would like to take a look I would have no problem giving user shell
access to the box.

Thanks,
Mitchell

dean.harding at dload

Jan 11, 2008, 4:12 AM

Post #16 of 26 (1486 views)
Permalink

Re: 64 Bit and memory [In reply to]

Mitch Gore wrote:
> mythfrontend processes each taking 9.4% of memory. And when there are
> 15 processes going for mythfrontend it eats everything up. When I
> killall mythfrontend the problem gets better. I can atleast run the

I think that's your problem: there should only be ONE mythfrontend
process! On my x86_64 system, I can mythfrontend for ages without
restarting it... (I don't know exactly how long... I usually restart it
for other reasons every few days as I'm playing around with stuff)

Where are they all coming from?

Dean.

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

mitchell.gore at gmail

Jan 11, 2008, 6:54 AM

Post #17 of 26 (1466 views)
Permalink

Re: 64 Bit and memory [In reply to]

> Where are they all coming from?
>
> Dean.
>
> _______________________________________________
>

So last night i believe i figured out the problem. It has to do with a
Media monitor patch that was put in earlier for me.

The issue first started when I upgraded to fedora 8 on my old hardware. It
was only 32bit but same case and pci cards. At this time i was running SVN
self compiled. i was seeing this spewed to the console when running
mythfrontend.

007-12-08 21:53:20.795 MythMediaDevice, Error: readlink() failed for
devpts:
eno: No such file or directory (2)
2007-12-08 21:53:20.795 MythMediaDevice, Error: readlink() failed for
tmpfs:
eno: No such file or directory (2)
2007-12-08 21:53: 20.795 MythMediaDevice, Error: readlink() failed for
/dev/sdb1:
eno: Invalid argument (22)
2007-12-08 21:53:20.795 MythMediaDevice, Error: readlink() failed for
/dev/sdc3:
eno: Invalid argument (22)
2007-12-08 21:53:20.795 MythMediaDevice, Error: readlink() failed for none:
eno: No such file or directory (2)
2007-12-08 21:53:20.796 MythMediaDevice, Error: readlink() failed for
sunrpc:
eno: No such file or directory (2)
2007-12-08 21:53:20.796 MythMediaDevice, Error: readlink() failed for
/etc/auto.misc:
eno: Invalid argument (22)
2007-12-08 21:53: 20.796 MythMediaDevice, Error: readlink() failed for
-hosts:
eno: No such file or directory (2)
2007-12-08 21:53:20.796 MythMediaDevice, Error: readlink() failed for
rootfs:
eno: No such file or directory (2)
2007-12-08 21:53:20.796 MythMediaDevice, Error: readlink() failed for
/dev/root:
eno: Invalid argument (22)
2007-12-08 21:53:20.796 MythMediaDevice, Error: readlink() failed for /dev:
eno: Invalid argument (22)

<http://www.nabble.com/user/UserProfile.jtp?user=825111>David George
responded back with *hack* fix to make it stop. This was then implemented
in ticket 4284. For then all was fine.

I saw this after the fix:
2007-12-09 14:05:07.247 MythMusic adding CD-Writer: 1,0,0 -- DVD+RW ND-1100A
2007-12-09 14:05:07.292 MonitorRegisterExtensions(0x40, ogg,mp3,aac,flac)
SIP listening on IP Address 192.168.0.202:5060 NAT address 192.168.0.202
SIP: Cannot register; proxy, username or password not set
2007-12-09 14:05:07.371 Starting media monitor.
2007-12-09 14:05:07.387 MythThemedMenuPrivate: Unknown tag image in
background
2007-12-09 14:05:07.389 Failed to mount /dev/sdd.
2007-12-09 14:05:07.391 Media status changed... (MEDIATYPE_DATA,
MEDIASTAT_UNPLUGGED -> MEDIASTAT_NOTMOUNTED)
2007-12-09 14:05:07.425 Failed to mount /dev/sde.
2007-12-09 14:05:07.428 Media status changed... (MEDIATYPE_DATA,
MEDIASTAT_UNPLUGGED -> MEDIASTAT_NOTMOUNTED)
2007-12-09 14:05:07.454 Failed to mount /dev/sdf.
2007-12-09 14:05:07.456 Media status changed... (MEDIATYPE_DATA,
MEDIASTAT_UNPLUGGED -> MEDIASTAT_NOTMOUNTED)
2007-12-09 14:05:07.480 Failed to mount /dev/sdg.
2007-12-09 14:05:07.483 Media status changed... (MEDIATYPE_DATA,
MEDIASTAT_UNPLUGGED -> MEDIASTAT_NOTMOUNTED)
2007-12-09 14:05:23.286 XMLParse::LoadTheme using
/usr/local/share/mythtv/themes/blootube-wide/ui.xml
2007-12-09 14:05:23.585 Connecting to backend server:
192.168.0.202:6543(try 1 of 5)
2007-12-09 14:05:23.586 Using protocol version 36

here is the thread:
http://www.nabble.com/F8-errors-when-running-SVN-console-td14235447s15552.html

Then i upgraded my motherboard, CPU, and RAM. I reinstalled F8 64 bit and
compiled SVN. I had some issue compiling, when this happened I thought
maybe it was my compile. So i installed ATrpms bleeding packages. Still
not fixed.

Last night when i was looking the cmd line of the FE i was wondering what
the heck is /dev/sde-f? Looking at hardware the only thing different in the
box from my other was it had 2 hard drives and a pvr-150 and the case an SD
reader on the front which plugged into USB headers.

I unplugged the SD card ports and those messages went away! I just ran
mythfrontend all last night and the comp only used 600 of the 950mb of RAM
and no SWAP.

So my conclusion is Media Monitor must have been spawning new threads of
Media Monitor and not closing them properly, they just kept making new ones
and eating memory. I'm going to put this in the ticket as well to see if we
can come up with a real fix.

I don't use the SD reader at all but some may for mythpictures, etc.

Mitchell

Axel.Thimm at ATrpms

Jan 11, 2008, 9:50 AM

Post #18 of 26 (1462 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Thu, Jan 10, 2008 at 09:43:06PM -0600, Mitch Gore wrote:
> I understand how linux does its memory usage and what not. But i am not
> talking about using alot of my memory and it being 'slower'. When I say
> slow the mouse wont even move fluidly. It jumps 1/2 way across the screen
> as i move it.

> Again I am using atrpms bleeding packages which are SVN r15333. I believe
> this my be a x86-64 issue. As my 32bit works fine with the same packages.
> both are F8 fully updated boxes.

Well, just a minor note, which may or may not be cause for this large
impact: The bleeding packages are built with "debug" instead of
optimized "release" build options. I wouldn't expect such a dramatic
influence, and especially not only on x86_64 vs i386.

I will do a rebuild of some newer 0.21 svn cut w/o debug options and
you may want to give them a test to see whether there is any
improvement in performance. Can you please pick this up with me in PM
or bugzilla, so I don't forget?
--
Axel.Thimm at ATrpms.net

Axel.Thimm at ATrpms

Jan 11, 2008, 9:59 AM

Post #19 of 26 (1465 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Fri, Jan 11, 2008 at 07:50:57PM +0200, Axel Thimm wrote:
> On Thu, Jan 10, 2008 at 09:43:06PM -0600, Mitch Gore wrote:
> > I understand how linux does its memory usage and what not. But i am not
> > talking about using alot of my memory and it being 'slower'. When I say
> > slow the mouse wont even move fluidly. It jumps 1/2 way across the screen
> > as i move it.
>
> > Again I am using atrpms bleeding packages which are SVN r15333. I believe
> > this my be a x86-64 issue. As my 32bit works fine with the same packages.
> > both are F8 fully updated boxes.
>
> Well, just a minor note, which may or may not be cause for this large
> impact: The bleeding packages are built with "debug" instead of
> optimized "release" build options. I wouldn't expect such a dramatic
> influence, and especially not only on x86_64 vs i386.

I read further on that you found the true reason for your performance
issues. :)

> I will do a rebuild of some newer 0.21 svn cut w/o debug options and
> you may want to give them a test to see whether there is any
> improvement in performance. Can you please pick this up with me in PM
> or bugzilla, so I don't forget?

I may do that anyhow as the ETA approaches to have people report on
better/worse performance that 0.20.x
--
Axel.Thimm at ATrpms.net

esejr at wildroseinternet

Jan 11, 2008, 11:12 AM

Post #20 of 26 (1460 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Thu, 10 Jan 2008 09:23:43 -0500, Richard Freeman
<r-mythtv [at] gw> wrote:
> Marc wrote:
>> I'm running a SVN(15354) frontend/backend on Gentoo with 32 bits and I'm
> not
>> seeing this problem.
>> asgard ~ # free -m
> > snip...
>
> I just noticed these posts. If you're concerned about memory leaks /
> etc looking at the output of free is just about useless. Look at how
> much memory individual processes are taking up instead.
>
> It is completely normal for a linux system with 500GB of memory and at
> least as much hard drive space to swap to disk, and report most of the
> memory as in use just about all the time.
>
> The reason memory seems to be always in-use is that "free" memory in
> linux is memory that is not being used AT ALL for any purpose. Linux
> tries to minimize the amount of completely-unused memory - preferring to
> use it for buffering or cache. When the memory is needed the cache is
> purged and the buffers are flushed. This only improves system
> performance by reducing disk access. If memory isn't needed for
> something else you might as well use it as cache - it doesn't cost
> anything as cache can be instantly purged to be made available.
>
snip...

I upgraded to SVN Revsion 15043 and I am no longer having this memory
issue. Whatever it was, it seems to have been fixed.

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

mitchell.gore at gmail

Jan 11, 2008, 1:02 PM

Post #21 of 26 (1462 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Jan 11, 2008 1:12 PM, Erik Sejr <esejr [at] wildroseinternet> wrote:

> On Thu, 10 Jan 2008 09:23:43 -0500, Richard Freeman
> <r-mythtv [at] gw> wrote:
> > Marc wrote:
> >> I'm running a SVN(15354) frontend/backend on Gentoo with 32 bits and
> I'm
> > not
> >> seeing this problem.
> >> asgard ~ # free -m
> > > snip...
> >
> > I just noticed these posts. If you're concerned about memory leaks /
> > etc looking at the output of free is just about useless. Look at how
> > much memory individual processes are taking up instead.
> >
> > It is completely normal for a linux system with 500GB of memory and at
> > least as much hard drive space to swap to disk, and report most of the
> > memory as in use just about all the time.
> >
> > The reason memory seems to be always in-use is that "free" memory in
> > linux is memory that is not being used AT ALL for any purpose. Linux
> > tries to minimize the amount of completely-unused memory - preferring to
> > use it for buffering or cache. When the memory is needed the cache is
> > purged and the buffers are flushed. This only improves system
> > performance by reducing disk access. If memory isn't needed for
> > something else you might as well use it as cache - it doesn't cost
> > anything as cache can be instantly purged to be made available.
> >
> snip...
>
> I upgraded to SVN Revsion 15043 and I am no longer having this memory
> issue. Whatever it was, it seems to have been fixed.
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>

Axel, when is the next spin of the SVN coming? I dont want to move back to
SVN self compile too much manual work!

Mitchell

Axel.Thimm at ATrpms

Jan 12, 2008, 9:04 AM

Post #22 of 26 (1442 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Fri, Jan 11, 2008 at 03:02:42PM -0600, Mitch Gore wrote:
> On Jan 11, 2008 1:12 PM, Erik Sejr <esejr [at] wildroseinternet> wrote:
> > I upgraded to SVN Revsion 15043 and I am no longer having this memory
> > issue. Whatever it was, it seems to have been fixed.
>
> Axel, when is the next spin of the SVN coming? I dont want to move back to
> SVN self compile too much manual work!

Unless there is a typo the latest bleeding packages are newer than
that (15333).
--
Axel.Thimm at ATrpms.net

esejr at wildroseinternet

Jan 13, 2008, 9:28 PM

Post #23 of 26 (1418 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Sat, 12 Jan 2008 19:04:48 +0200, Axel Thimm <Axel.Thimm [at] ATrpms>
wrote:
> On Fri, Jan 11, 2008 at 03:02:42PM -0600, Mitch Gore wrote:
>> On Jan 11, 2008 1:12 PM, Erik Sejr <esejr [at] wildroseinternet> wrote:
>> > I upgraded to SVN Revsion 15043 and I am no longer having this memory
>> > issue. Whatever it was, it seems to have been fixed.
>>
>> Axel, when is the next spin of the SVN coming? I dont want to move
> back to
>> SVN self compile too much manual work!
>
> Unless there is a typo the latest bleeding packages are newer than
> that (15333).
>
Yes, it was A typo, that should have been 15403.

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Axel.Thimm at ATrpms

Jan 15, 2008, 12:40 PM

Post #24 of 26 (1372 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Sun, Jan 13, 2008 at 10:28:00PM -0700, Erik Sejr wrote:
>
>
> On Sat, 12 Jan 2008 19:04:48 +0200, Axel Thimm <Axel.Thimm [at] ATrpms>
> wrote:
> > On Fri, Jan 11, 2008 at 03:02:42PM -0600, Mitch Gore wrote:
> >> On Jan 11, 2008 1:12 PM, Erik Sejr <esejr [at] wildroseinternet> wrote:
> >> > I upgraded to SVN Revsion 15043 and I am no longer having this memory
> >> > issue. Whatever it was, it seems to have been fixed.
> >>
> >> Axel, when is the next spin of the SVN coming? I dont want to move
> > back to
> >> SVN self compile too much manual work!
> >
> > Unless there is a typo the latest bleeding packages are newer than
> > that (15333).
> >
> Yes, it was A typo, that should have been 15403.

OK, I'll upload 15447 later today.
--
Axel.Thimm at ATrpms.net

sdkovacs at gmail

Jan 15, 2008, 1:16 PM

Post #25 of 26 (1373 views)
Permalink

Re: 64 Bit and memory [In reply to]

On Jan 15, 2008 3:40 PM, Axel Thimm <Axel.Thimm [at] atrpms> wrote:
>
> OK, I'll upload 15447 later today.
>
> --
> Axel.Thimm at ATrpms.net

Will that be a 'debug' or 'release' package? I need to run the
bleeding packages for PVR-350 output on 2.6.23, and I'd love to be
running the 'release' on my wimpy hardware.

Thanks.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads