2020. március 30., hétfő 19:44:05 UTC+2 időpontban Nitish Saboo a
következőt írta:
>
> Hi,
>
> Requesting valuable inputs on this.
>
> Thanks,
> Nitish
>
> On Thu, Mar 26, 2020 at 5:08 PM Nitish Saboo > wrote:
>
>> Hi Tamas,
>>
>> 1) There is no such option '--heap_inuse'. We have an
It has already been answered. The alloc size is not the mem in use heap size.
> On Mar 30, 2020, at 12:43 PM, Nitish Saboo wrote:
>
>
> Hi,
>
> Requesting valuable inputs on this.
>
> Thanks,
> Nitish
>
>> On Thu, Mar 26, 2020 at 5:08 PM Nitish Saboo
>> wrote:
>> Hi Tamas,
>>
>> 1)
Hi,
Requesting valuable inputs on this.
Thanks,
Nitish
On Thu, Mar 26, 2020 at 5:08 PM Nitish Saboo
wrote:
> Hi Tamas,
>
> 1) There is no such option '--heap_inuse'. We have an -*-inuse_space*
> option. Is this what you are talking about?
>
> nsaboo@ubuntu:~/Desktop/memprof$ go tool pprof
Hi Tamas,
1) There is no such option '--heap_inuse'. We have an -*-inuse_space*
option. Is this what you are talking about?
nsaboo@ubuntu:~/Desktop/memprof$ go tool pprof --inuse_space main mem3.prof
Fetched 1 source profiles out of 2
File: main
Build ID: 99b8f2b91a4e037cf4a622aa32f2c1866764e7eb
Correct. I didn’t read the output... :) I just assumed the OP was doing that...
my bad.
> On Mar 24, 2020, at 1:46 PM, Tamás Gulácsi wrote:
>
>
> You've requested the total allocated space (--alloc_space), not only the heap
> used (--heap_inuse, or no flag).
> So that 17GiB is the total
You've requested the total allocated space (--alloc_space), not only the
heap used (--heap_inuse, or no flag).
So that 17GiB is the total allocated size, does NOT include the released!
2020. március 24., kedd 15:16:46 UTC+1 időpontban Nitish Saboo a következőt
írta:
>
> Hi,
>
> I have already
You have virtual memory most likely. The in use is clearly 17gb.
> On Mar 24, 2020, at 9:16 AM, Nitish Saboo wrote:
>
>
> Hi,
>
> I have already gone through those links. They helped me to gather the mem
> profile and while analyzing the data(as given in those links) I have come
> across
Hi,
I have already gone through those links. They helped me to gather the mem
profile and while analyzing the data(as given in those links) I have come
across the following issue:
While I was running the service for 100 minutes the 'top' command output
was showing Mem% as 11.1. There was no
Sorry not paper, two websites I gave you previously.
> On Mar 24, 2020, at 7:02 AM, Nitish Saboo wrote:
>
>
> Hi,
>
> >>There is no root analysis available in Go. Read the paper I linked to.
>
> Sorry I did not get you. Which paper are you referring to?
>
> While I was running the
Hi,
>>There is no root analysis available in Go. Read the paper I linked to.
Sorry I did not get you. Which paper are you referring to?
While I was running the service for 100 minutes the 'top' command output
was showing Mem% as 11.1. There was no increase in mem usage since I had
not called
Yes. You have a leak in your Go code. It shows you the object types that are
taking up all of the space. There is no root analysis available in Go. Read the
paper I linked to.
> On Mar 23, 2020, at 9:12 AM, Nitish Saboo wrote:
>
>
> Hi,
>
> I used something like the following to generate
Hi,
I used something like the following to generate a memprof for 100 minutes
func main() {
flag.Parse()
if *cpuprofile != "" {
f, err := os.Create(*cpuprofile)
if err != nil {
fmt.Println("could not create CPU profile: ", err)
}
defer f.Close() // error handling omitted for example
if err :=
And
https://blog.golang.org/pprof
> On Mar 19, 2020, at 9:27 AM, Robert Engels wrote:
>
>
> https://www.freecodecamp.org/news/how-i-investigated-memory-leaks-in-go-using-pprof-on-a-large-codebase-4bec4325e192/amp/
>
>>> On Mar 19, 2020, at 9:24 AM, Nitish Saboo wrote:
>>>
>>
>> Hi,
>>
https://www.freecodecamp.org/news/how-i-investigated-memory-leaks-in-go-using-pprof-on-a-large-codebase-4bec4325e192/amp/
> On Mar 19, 2020, at 9:24 AM, Nitish Saboo wrote:
>
>
> Hi,
>
> Are there any other commands that provide an exact allocation of memory for
> each of the functions or
Hi,
Are there any other commands that provide an exact allocation of memory for
each of the functions or help to analyze the memory allocation much better?
Thanks,
Nitish
On Thu, Mar 19, 2020 at 7:08 PM Robert Engels wrote:
> You are only using 1.5 mb on the Go side... so if your process is
>
You are only using 1.5 mb on the Go side... so if your process is consuming
lots of memory it’s on the C side.
> On Mar 19, 2020, at 7:55 AM, Nitish Saboo wrote:
>
>
> Hi Michael,
>
> I used something like this to generate a mem-prof for 60 minutes
>
> func main() {
> flag.Parse()
> if
Hi Michael,
I used something like this to generate a mem-prof for 60 minutes
func main() {
flag.Parse()
if *cpuprofile != "" {
f, err := os.Create(*cpuprofile)
if err != nil {
fmt.Println("could not create CPU profile: ", err)
}
defer f.Close() // error handling omitted for example
if err :=
Hi,
Yeah, even I did not expect the program to have 29% memory usage.Not sure
if this is how the Go GC works.
Thanks,
Nitish
On Wed, Mar 18, 2020 at 12:48 AM Robert Engels
wrote:
> My only thought was that maybe you had more Go routines accessing it than
> you thought.
>
> It is remains
My only thought was that maybe you had more Go routines accessing it than you
thought.
It is remains constant after a while it is most likely not a memory leak. It is
done what surprising that the memory consumption in a steady state would be 4x
the equivalent C program.
> On Mar 17, 2020,
Hi Robert,
Thanks for your response.
Since patterndb is a global variable(not a thread-local variable) and I
have a single goroutine that calls load_pattern_db() method, therefore it
was not looking correct to me to pin a goroutine to a thread.
I once again tested the code flow. Apologies for
I’ve been thinking about this some more, and I think that LockOSThread() should
not be needed - that the Go thread multiplexing must perform memory fences
otherwise the simplest of Go apps would have concurrency issues.
So, that leads me to believe that your “single routine” is not correct. I
In the single Go routine, use LockOSThread(). Then it was always be accessed on
the same thread removing the memory synchronization problems.
> On Mar 16, 2020, at 11:28 AM, Nitish Saboo wrote:
>
>
> Hi,
>
> So finally I got a little hint of the problem from what Robert described
>
Hi,
So finally I got a little hint of the problem from what Robert described
earlier in the mail. Thank you so much Robert.
Looks like patterndb instance is not getting freed.
node.c
-
PatternDB *patterndb;
int load_pattern_db(const gchar* file, key_value_cb cb)
{
if(patterndb !=
Hi Robert,
Sorry I did not understand your point completely.
I have a global variable patterndb on C side and It is getting called from
a single goroutine every 3 mins. Why do I need to synchronize it?
Even though the goroutine gets pinned to different threads, it can access
the same global
Yes, you have a shared global variable you need to synchronize.
> On Mar 16, 2020, at 9:35 AM, Nitish Saboo wrote:
>
>
> Hi,
>
> Are you saying it is working as expected?
>
> Thanks,
> Nitish
>
>> On Mon, Mar 16, 2020 at 7:42 PM Volker Dobler
>> wrote:
>>> On Monday, 16 March 2020
Hi,
Are you saying it is working as expected?
Thanks,
Nitish
On Mon, Mar 16, 2020 at 7:42 PM Volker Dobler
wrote:
> On Monday, 16 March 2020 14:25:52 UTC+1, Nitish Saboo wrote:
>>
>> Hi,
>>
>> I upgraded the go version and compiled the binary against go version 'go
>> version go1.12.4
On Monday, 16 March 2020 14:25:52 UTC+1, Nitish Saboo wrote:
>
> Hi,
>
> I upgraded the go version and compiled the binary against go version 'go
> version go1.12.4 linux/amd64'.
> I ran the program for some time. I made almost 30-40 calls to the method
> Load_Pattern_Db().
> The program starts
Sounds like it. Probably in the C code. You need to check that your
release/free code is correct.
You can try a similar C program that instantiates and frees the structure to
check for similar behavior.
> On Mar 16, 2020, at 8:25 AM, Nitish Saboo wrote:
>
>
> Hi,
>
> I upgraded the go
Hi,
I upgraded the go version and compiled the binary against go version 'go
version go1.12.4 linux/amd64'.
I ran the program for some time. I made almost 30-40 calls to the method
Load_Pattern_Db().
The program starts with 6% Mem Usage. The memory usage increases only when
I call
hi. get the time at the start, check the elapsed time in your infinite
loop, and trigger the write/exit after a minute, 10 minutes, 100 minutes,
...
On Fri, Mar 13, 2020 at 5:45 AM Nitish Saboo
wrote:
> Hi Michael,
>
> Thanks for your response.
>
> That code looks wrong. I see the end but not
Hi Michael,
Thanks for your response.
That code looks wrong. I see the end but not the start. Look here and copy
carefully:
>>Since I did not want cpu profiling I omitted the start of the code and
just added memory profiling part.
Call at end, on way out.
>>Oh yes, I missed that.I have to
That code looks wrong. I see the end but not the start. Look here and copy
carefully:
https://golang.org/pkg/runtime/pprof/
Call at end, on way out.
Also, as shared by others above, there are no promises about how soon the
dead allocations go away, The speed gets faster and faster version to
Hi,
I have compiled my Go binary against go version 'go1.7 linux/amd64'.
I added the following code change in the main function to get the memory
profiling of my service
var memprofile = flag.String("memprofile", "", "write memory profile to
`file`")
func main() {
flag.Parse()
if *memprofile !=
On Monday, March 9, 2020 at 1:37:00 PM UTC-4, Nitish Saboo wrote:
>
> Hi Jake,
>
> The memory usage remains constant when the rest of the service is
> running.Only when LoadPatternDB() method is called within the service,
> Memory Consumption increases which actually should not happen.
> I am
Hi Jake,
The memory usage remains constant when the rest of the service is
running.Only when LoadPatternDB() method is called within the service,
Memory Consumption increases which actually should not happen.
I am assuming if there is a memory leak while calling this method because
the memory
You may indeed have a leak. I did not check your code that carefully. But i
do wonder about your statement:
>
> 1)As soon as I call LoadPatternDB() method in parser.go there is some
> increase in memory consumption(some memory leak). Ideally that should not
> have happened.
>
Go is a garbage
36 matches
Mail list logo
