Raheel Gupta wrote:
> Sir, is there any way to not allow malloc to hold memory ? I mean shouldnt
> free(), be freeing the memory ?
free() frees memory in the heap, making it available to other
malloc again. But it does not necessarily shrink the amount of
memory used by the process as was alread
On Tue, Oct 29, 2013 at 01:22:39AM +0530, Raheel Gupta wrote:
> Sir, is there any way to not allow malloc to hold memory ? I mean shouldnt
> free(), be freeing the memory ?
No. The way malloc() typically works is that it allocates large chunks
of memory from the OS's kernel, then it allocates chu
On 28/10/2013 3:57 PM, Richard Hipp wrote:
On Mon, Oct 28, 2013 at 3:52 PM, Raheel Gupta wrote:
Sir, is there any way to not allow malloc to hold memory ? I mean shouldnt
free(), be freeing the memory ?
You'lll need to speak with the developers of your libc implementation about
that.
... but
On Mon, Oct 28, 2013 at 3:52 PM, Raheel Gupta wrote:
> Sir, is there any way to not allow malloc to hold memory ? I mean shouldnt
> free(), be freeing the memory ?
>
You'lll need to speak with the developers of your libc implementation about
that.
--
D. Richard Hipp
d...@sqlite.org
Sir, is there any way to not allow malloc to hold memory ? I mean shouldnt
free(), be freeing the memory ?
On Tue, Oct 29, 2013 at 1:19 AM, Richard Hipp wrote:
> On Mon, Oct 28, 2013 at 3:47 PM, Raheel Gupta wrote:
>
> >
> > Then I ran "Pragma shrink_memory"
> >
> > Memory Used:
On Mon, Oct 28, 2013 at 3:47 PM, Raheel Gupta wrote:
>
> Then I ran "Pragma shrink_memory"
>
> Memory Used: 152584 (max 131658680) bytes
> Number of Outstanding Allocations: 79 (max 2081)
>
So, after running "PRAGMA shrink_memory", SQLite has reduced its memory
holdings
Hi,
After running my query :
Memory Used: 131655360 (max 131656000) bytes
Number of Outstanding Allocations: 2079 (max 2081)
Number of Pcache Overflow Bytes: 131567752 (max 131567752) bytes
Number of Scratch Overflow Bytes:0 (max 0) bytes
Largest Allocation:
On Mon, Oct 28, 2013 at 9:16 AM, Raheel Gupta wrote:
> >> Whether or not free() returns that space to the operating system or
> keeps
> it around to satisfy future malloc() calls is a detail of the
> implementation of free().
>
> Sir, anyway to be sure of that ?
>
> In the command-line shell, do
>> Whether or not free() returns that space to the operating system or keeps
it around to satisfy future malloc() calls is a detail of the
implementation of free().
Sir, anyway to be sure of that ?
On Mon, Oct 28, 2013 at 5:45 PM, Richard Hipp wrote:
> On Mon, Oct 28, 2013 at 8:13 AM, Raheel
On Mon, Oct 28, 2013 at 8:13 AM, Raheel Gupta wrote:
> >> Then you have answered your question. The amount of memory still being
> used is the size of the cache.
>
> Sir, that is the PEAK usage it goes upto.
> After "PRAGMA shrink_memory" it goes down only to 65MB, which is 1000 Pages
> as per 64
>> Then you have answered your question. The amount of memory still being
used is the size of the cache.
Sir, that is the PEAK usage it goes upto.
After "PRAGMA shrink_memory" it goes down only to 65MB, which is 1000 Pages
as per 64K page sizes.
Shouldnt it go down to the original usage of around
On 28 Oct 2013, at 10:45am, Raheel Gupta wrote:
>>> PRAGMA cache_size
>
> I have set that 2000 in both cases.
Then you have answered your question. The amount of memory still being used is
the size of the cache.
Simon.
___
sqlite-users mailing lis
>> If you multiply that by your page size do you get the amount of memory
you see being used
During peak usage the memory reaches 126 MB which is similar to 2000 x 64K.
After "PRAGMA shrink_memory" it goes down only to 65MB, which is 1000 Pages
as per 64K page sizes.
On Mon, Oct 28, 2013 at 4:
>> PRAGMA cache_size
I have set that 2000 in both cases.
On Sun, Oct 27, 2013 at 7:49 PM, Simon Slavin wrote:
>
> On 27 Oct 2013, at 5:10am, Raheel Gupta wrote:
>
> > But why would this happen with 64K pages ? In 1024 Sqlite is able to
> > release all the memory.
>
> I doubt it's releasing al
On 27 Oct 2013, at 5:10am, Raheel Gupta wrote:
> But why would this happen with 64K pages ? In 1024 Sqlite is able to
> release all the memory.
I doubt it's releasing all the memory. It's probably holding on to a few
pages. But the pages are so small that the memory usage doesn't register.
Raheel Gupta wrote:
> Hi,
>
> Yes, I tried Valgrind and it shows no leaks.
> But why would this happen with 64K pages ? In 1024 Sqlite is able to
> release all the memory.
>
>>> It might also be that your memory allocator is holding onto freed memory
> rather than releasing it back to the OS.
>
>
>> Whether and how you can do so will depend on what operating system you
are
using.
I am using a CentOS 6.4
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Whether and how you can do so will depend on what operating system you are
using.
On 27 October 2013 16:10, Raheel Gupta wrote:
> Hi,
>
> Yes, I tried Valgrind and it shows no leaks.
> But why would this happen with 64K pages ? In 1024 Sqlite is able to
> release all the memory.
>
> >> It might
Hi,
Yes, I tried Valgrind and it shows no leaks.
But why would this happen with 64K pages ? In 1024 Sqlite is able to
release all the memory.
>> It might also be that your memory allocator is holding onto freed memory
rather than releasing it back to the OS.
How should I free it ?
On Sun, Oct
On Sun, Oct 27, 2013 at 12:02 AM, Raheel Gupta wrote:
> Hi,
>
> Sir, if you see my first email, I have already tried that. When the 15
> Million records are being outputted, the ram usage shoots to a MAX of
> 126MB. After the "PRAGMA shrink_memory" it goes down to 65Mb but doesnt go
> below that.
Hi,
Sir, if you see my first email, I have already tried that. When the 15
Million records are being outputted, the ram usage shoots to a MAX of
126MB. After the "PRAGMA shrink_memory" it goes down to 65Mb but doesnt go
below that.
On Sun, Oct 27, 2013 at 4:55 AM, Richard Hipp wrote:
> On Sat,
>> Try letting SQLite use its default for your platform.
The default when the database is created is 1024.
It works well in that page size as I have mentioned in my first email.
The issue is with 65536.
Why should there be a memory leak when the page size is 65536 ?
I have to use 65536 to enable
On Sat, Oct 26, 2013 at 3:03 PM, Raheel Gupta wrote:
>
> This leads me to conclude that there is some kind of Memory Leakage when
> the page size is 64K.
>
> How can I bring down the memory usage atleast when I shrink_memory after
> the query executes.
>
Doubtful. Probably the excess memory is
On 26 Oct 2013, at 8:03pm, Raheel Gupta wrote:
> How can I bring down the memory usage atleast when I shrink_memory after
> the query executes.
You stop using such big pages.
Try letting SQLite use its default for your platform. Do an export and
reimport without using any PRAGMAs at all. Th
Hi,
I am using a Page Size of 65536 and I have found the performance good
enough for me until now.
I have the database having the following table:
CREATE TABLE map (
n BIGINT NOT NULL DEFAULT 0,
s INT(5) NOT NULL DEFAULT 0,
d INT(5) NOT NULL DEFAULT 0,
c INT(1) NOT NULL DEFAULT 0,
b UNSIGNED BIGI
25 matches
Mail list logo
