Tianji install - maybe bad var naming ?

[minor mulch]

Hello , i'm in trouble installing tiabji trought pve help script , default install no tweak lead to trouble when we cat info to le .env ( l39)
https://github.com/community-scripts/ProxmoxVE/blob/main/install/tianji-install.sh#L40C6-L40C84
(see images)
maybe PG_DB_NAME PG_DB_USER is not at the inteeed for templatin the string : DATABASE_URL="postgresql://$DB_USER:$DB_PASS@localhost:5432/$DB_NAME?schema=public"

and db pass i don't know where it's populated ? maybe i'm all wrong, i'm just discovering pve helper script there's maybe some magic processes behinf the secen when creating postgres ..

othe thing to mention when getting / compiling tianji with default memoy allocation it lead to be fully occupied and swap hardly :
see memory usage, maybe it could be nice to add limite to node telling it's running ont 4gb memory system ( node not my main competence but i think it near those option : max_old_space_size for NODE_OPTIONS
when giving 8go memory during pnpm phase it lead to , so maybe a little bit more of 4gb by defaut should be great (beccause when swap occrus , everything get very hard and laggy )

[indigo anchor]

yes this is a typo in the script

fix incoming

[minor mulch]

okay :! and for the mode option i see that cd /opt/tianji
export NODE_OPTIONS="--max_old_space_size=4096"

is present on the update script part , but not on the fresh install i think ? 🙂

Node option : https://github.com/community-scripts/ProxmoxVE/blob/main/ct/tianji.sh#L47C1-L47C52 ( but only for updating ? )

thanks @indigo anchor for the reactivity !

[indigo anchor]

the NODE_OPTIONS can be ignored as the container itself has 4GB of RAM

so it basically does nothing

probably remnant of some previous installation method where it was required

[minor mulch]

does it tell node when building with pnpm to manage with 4gb in total ( as xmx and so on on java ) cause as we htting the max memory of the container , swaping conduct to a 30 min pnpm build

And as i said i'm not such a expert in node tweking env and so on so if you tell tha tits does nothing i believe u 😉 just sharing my experience

Thanks for the fix, by the way!

[indigo anchor]

that command basicaly limits the V8 heap

and should be set like Total RAM - 512MB

something along those lines, obviously every app should be tweaked accordingly

but i think this was copied directly from their dockerfile, so.... i'm not sure

as apps get updated, its possible that we need to increase the RAM for the container

we used to have app in the repo that didnt want to build unless given at least 12GB of RAM

[minor mulch]

Yes , from my experience sometimes language compiler ( especially on virtualized env ) aren't ccatching properly how much ressources they have ( for example java + docker some year ago , despite the limit , the heap want to increase and preheat based on the host ressources .. not the limited container resources ) i dont know if lxc and node are impacted of this

as the defaut var_ram="${var_ram:-4096}" and seems to be a little bit tight if nobody tells that there is not so much ram available as usual specs

but thanks for the explanation

[indigo anchor]

the app just wont build unless it has at least 4GB available

its what they wrote in their repo 🙂

[minor mulch]

yes u see my SS , it build but , i think swapped all the ram and so on , that why took 30 minute istead 1-2 minute if i give more ram space of the container ( os is taking a little bit i think )

[indigo anchor]

so basically that command will use all container RAM for the build, while the rest will probably be swapped around, but after the build finishes it will drop a lot

[minor mulch]

idk if its possible with your proxmox scripts to give ressources for the build ( and update part ) and then reduce ressource alocated to the lxc for the run

just wrote as i'm thinking how harden stability of a fresh install ( and possibly the updating phase )

[indigo anchor]

not atm

you can always give temporary resources with var_cpu and var_ram and var_disk

then after install finishes, you can scale it back

[minor mulch]

yes ofc i did it , i'm thinking for futures user's and one command install as smooth as possible 🙂

[indigo anchor]

we cant really know ahead of time if app suddenly needs more resources

we set sensible default so the build/install can pass without issues

then its up to the user to adjust resources according to his use case

[minor mulch]

i understand , bu as it's the build phase there is no user's need at this moment of installation , i don't know if i'm explain my tought correctly as my english is pretty bad

[indigo anchor]

no we cant dinamicaly set resources as install stage is happening inside the container, where you have no control over the container

also, we cant just throw numbers around, as people have different machines running PVE

we cant set container to use 16GB just because it will work better, as most of homelabs run on old Dell minipc and stuff, with limited RAM options

[minor mulch]

yes allocation

start
build_container
description

is on start.. after you are going to install phase .. after that ..

[minor mulch]

that's not what's i'm saying

anyway thanks for the typo , and for the other parts, i'm just trying to find some solution and have reflexions with u for not swaping the container during install phase..

bye.

for me it's as the same as buying a new car with inflated tires, every new buyer should inflate the tire to have the experience they wan't with byuing a brand new car...

you can inflate ( increasing ram ) for sure, but it's not practical and the probleme is known from the begining

but maybe i'm tired, have gn