On 26/06/18 09:40, Salvatore D'angelo wrote: > Hi, > > Yes, > > I am reproducing only the required part for test. I think the original > system has a larger shm. The problem is that I do not know exactly how > to change it. > I tried the following steps, but I have the impression I didn’t > performed the right one: > > 1. remove everything under /tmp > 2. Added the following line to /etc/fstab > tmpfs /tmp tmpfs defaults,nodev,nosuid,mode=1777,size=128M > 0 0 > 3. mount /tmp > 4. df -h > Filesystem Size Used Avail Use% Mounted on > overlay 63G 11G 49G 19% / > tmpfs 64M 4.0K 64M 1% /dev > tmpfs 1000M 0 1000M 0% /sys/fs/cgroup > osxfs 466G 158G 305G 35% /Users > /dev/sda1 63G 11G 49G 19% /etc/hosts > shm 64M 11M 54M 16% /dev/shm > tmpfs 1000M 0 1000M 0% /sys/firmware > *tmpfs 128M 0 128M 0% /tmp* > > The errors are exactly the same. > I have the impression that I changed the wrong parameter. Probably I > have to change: > shm 64M 11M 54M 16% /dev/shm > > but I do not know how to do that. Any suggestion? >
According to google, you just add a new line to /etc/fstab for /dev/shm tmpfs /dev/shm tmpfs defaults,size=512m 0 0 Chrissie >> On 26 Jun 2018, at 09:48, Christine Caulfield <ccaul...@redhat.com >> <mailto:ccaul...@redhat.com>> wrote: >> >> On 25/06/18 20:41, Salvatore D'angelo wrote: >>> Hi, >>> >>> Let me add here one important detail. I use Docker for my test with 5 >>> containers deployed on my Mac. >>> Basically the team that worked on this project installed the cluster >>> on soft layer bare metal. >>> The PostgreSQL cluster was hard to test and if a misconfiguration >>> occurred recreate the cluster from scratch is not easy. >>> Test it was a cumbersome if you consider that we access to the >>> machines with a complex system hard to describe here. >>> For this reason I ported the cluster on Docker for test purpose. I am >>> not interested to have it working for months, I just need a proof of >>> concept. >>> >>> When the migration works I’ll port everything on bare metal where the >>> size of resources are ambundant. >>> >>> Now I have enough RAM and disk space on my Mac so if you tell me what >>> should be an acceptable size for several days of running it is ok for me. >>> It is ok also have commands to clean the shm when required. >>> I know I can find them on Google but if you can suggest me these info >>> I’ll appreciate. I have OS knowledge to do that but I would like to >>> avoid days of guesswork and try and error if possible. >> >> >> I would recommend at least 128MB of space on /dev/shm, 256MB if you can >> spare it. My 'standard' system uses 75MB under normal running allowing >> for one command-line query to run. >> >> If I read this right then you're reproducing a bare-metal system in >> containers now? so the original systems will have a default /dev/shm >> size which is probably much larger than your containers? >> >> I'm just checking here that we don't have a regression in memory usage >> as Poki suggested. >> >> Chrissie >> >>>> On 25 Jun 2018, at 21:18, Jan Pokorný <jpoko...@redhat.com >>>> <mailto:jpoko...@redhat.com>> wrote: >>>> >>>> On 25/06/18 19:06 +0200, Salvatore D'angelo wrote: >>>>> Thanks for reply. I scratched my cluster and created it again and >>>>> then migrated as before. This time I uninstalled pacemaker, >>>>> corosync, crmsh and resource agents with make uninstall >>>>> >>>>> then I installed new packages. The problem is the same, when >>>>> I launch: >>>>> corosync-quorumtool -ps >>>>> >>>>> I got: Cannot initialize QUORUM service >>>>> >>>>> Here the log with debug enabled: >>>>> >>>>> >>>>> [18019] pg3 corosyncerror [QB ] couldn't create circular mmap >>>>> on /dev/shm/qb-cfg-event-18020-18028-23-data >>>>> [18019] pg3 corosyncerror [QB ] >>>>> qb_rb_open:cfg-event-18020-18028-23: Resource temporarily >>>>> unavailable (11) >>>>> [18019] pg3 corosyncdebug [QB ] Free'ing ringbuffer: >>>>> /dev/shm/qb-cfg-request-18020-18028-23-header >>>>> [18019] pg3 corosyncdebug [QB ] Free'ing ringbuffer: >>>>> /dev/shm/qb-cfg-response-18020-18028-23-header >>>>> [18019] pg3 corosyncerror [QB ] shm connection FAILED: >>>>> Resource temporarily unavailable (11) >>>>> [18019] pg3 corosyncerror [QB ] Error in connection setup >>>>> (18020-18028-23): Resource temporarily unavailable (11) >>>>> >>>>> I tried to check /dev/shm and I am not sure these are the right >>>>> commands, however: >>>>> >>>>> df -h /dev/shm >>>>> Filesystem Size Used Avail Use% Mounted on >>>>> shm 64M 16M 49M 24% /dev/shm >>>>> >>>>> ls /dev/shm >>>>> qb-cmap-request-18020-18036-25-data qb-corosync-blackbox-data >>>>> qb-quorum-request-18020-18095-32-data >>>>> qb-cmap-request-18020-18036-25-header qb-corosync-blackbox-header >>>>> qb-quorum-request-18020-18095-32-header >>>>> >>>>> Is 64 Mb enough for /dev/shm. If no, why it worked with previous >>>>> corosync release? >>>> >>>> For a start, can you try configuring corosync with >>>> --enable-small-memory-footprint switch? >>>> >>>> Hard to say why the space provisioned to /dev/shm is the direct >>>> opposite of generous (per today's standards), but may be the result >>>> of automatic HW adaptation, and if RAM is so scarce in your case, >>>> the above build-time toggle might help. >>>> >>>> If not, then exponentially increasing size of /dev/shm space is >>>> likely your best bet (I don't recommended fiddling with mlockall() >>>> and similar measures in corosync). >>>> >>>> Of course, feel free to raise a regression if you have a reproducible >>>> comparison between two corosync (plus possibly different libraries >>>> like libqb) versions, one that works and one that won't, in >>>> reproducible conditions (like this small /dev/shm, VM image, etc.). >>>> >>>> -- >>>> Jan (Poki) >>>> _______________________________________________ >>>> Users mailing list: Users@clusterlabs.org <mailto:Users@clusterlabs.org> >>>> https://lists.clusterlabs.org/mailman/listinfo/users >>>> >>>> Project Home: http://www.clusterlabs.org >>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>>> Bugs: http://bugs.clusterlabs.org >>> >>> _______________________________________________ >>> Users mailing list: Users@clusterlabs.org <mailto:Users@clusterlabs.org> >>> https://lists.clusterlabs.org/mailman/listinfo/users >>> >>> Project Home: http://www.clusterlabs.org <http://www.clusterlabs.org/> >>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>> Bugs: http://bugs.clusterlabs.org <http://bugs.clusterlabs.org/> >>> >> >> _______________________________________________ >> Users mailing list: Users@clusterlabs.org <mailto:Users@clusterlabs.org> >> https://lists.clusterlabs.org/mailman/listinfo/users >> >> Project Home: http://www.clusterlabs.org <http://www.clusterlabs.org/> >> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >> Bugs: http://bugs.clusterlabs.org <http://bugs.clusterlabs.org/> > > > > _______________________________________________ > Users mailing list: Users@clusterlabs.org > https://lists.clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org > _______________________________________________ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
