On 05/01/2017 08:41 AM, VENKTESH GUTTEDAR wrote:
> Hello All,
>
> Base directory is consuming to much memory, leading to no space on
> server and stopping the application
I am going to say that you mean that the base directory is consuming too
much disk space, correct?
If not can you be specific about what you mean?
Maybe output from a command that shows the issue?
>
> Somebody please explain why it takes so much memory and is it safe
> to delete those files.?
Well if you are talking about the base directory in the Postgres
cluster, them that is where the database data is stored:
https://www.postgresql.org/docs/9.6/static/storage-file-layout.html
"base Subdirectory containing per-database subdirectories
...
For each database in the cluster there is a subdirectory within
PGDATA/base, named after the database's OID in pg_database. This
subdirectory is the default location for the database's files; in
particular, its system catalogs are stored there.
Each table and index is stored in a separate file. For ordinary
relations, these files are named after the table or index's filenode
number, which can be found in pg_class.relfilenode. But for temporary
relations, the file name is of the form tBBB_FFF, where BBB is the
backend ID of the backend which created the file, and FFF is the
filenode number. In either case, in addition to the main file (a/k/a
main fork), each table and index has a free space map (see Section
65.3), which stores information about free space available in the
relation. The free space map is stored in a file named with the filenode
number plus the suffix _fsm. Tables also have a visibility map, stored
in a fork with the suffix _vm, to track which pages are known to have no
dead tuples. The visibility map is described further in Section 65.4.
Unlogged tables and indexes have a third fork, known as the
initialization fork, which is stored in a fork with the suffix _init
(see Section 65.5)."
So if it is growing it is because the databases are growing.
>
> --
> Regards :
> Venktesh Guttedar.
>
--
Adrian Klaver
adrian.klaver@aklaver.com