From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Virus-Scanned: amavisd-new at elserv.ru Message-ID: <520BB348.2000902@elserv.msk.su> Date: Wed, 14 Aug 2013 20:41:44 +0400 From: Alex Moskalenko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130610 Thunderbird/17.0.6 MIME-Version: 1.0 To: ALT Linux sysadmins' discussion Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [Sysadmins] =?utf-8?q?OpenVZ_CT=2C_PostgreSQL_=D0=B8_Shared_memor?= =?utf-8?q?y?= X-BeenThere: sysadmins@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux sysadmins' discussion List-Id: ALT Linux sysadmins' discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 16:41:51 -0000 Archived-At: List-Archive: Здравствуйте! Поделитесь пожалуйста опытом работы с PostgreSQL в контейнере OpenVZ. Начиная с ядер 2.6.32-ovz-el-alt75 и заканчивая 2.6.32-ovz-el-alt100 наблюдаю одну и ту же картину: в процессе работы контейнера серверный процесс PostgreSQL падает с SIGBUS, после чего мастер-процесс перезапускает все остальные серверные процессы. Ситуация проявляется далеко не сразу, а по прошествии некоторого времени с момента старта контейнера. При анализе ситуации выяснилось, что контейнер приближается к лимиту по physpages (используется VSwap, поэтому все остальное - unlimited). Основной потребитель памяти - дисковый кэш. При этом никакие лимиты никогда не превышаются и failcnt (по всем ресурсам) всегда ноль. Когда текущее значение physpages приближается к лимиту, PostgreSQL выдает следующее: 2013-08-08 14:27:51 MSK [26800] host=[local] db=db user=db: ERROR: could not read block 2981 in file "base/88880/89603": read only 5216 of 8192 bytes 2013-08-08 14:27:51 MSK [26676] host=[local] db=db user=db: ERROR: could not read block 2981 in file "base/88880/89603": read only 5216 of 8192 bytes 2013-08-08 14:27:52 MSK [26813] host=[local] db=db user=db: ERROR: could not read block 2981 in file "base/88880/89603": read only 5216 of 8192 bytes 2013-08-08 14:27:56 MSK [26524] host= db= user=: LOG: server process (PID 26753) was terminated by signal 7: Bus error 2013-08-08 14:27:56 MSK [26524] host= db= user=: LOG: terminating any other active server processes Описание проблемы похоже на http://www.postgresql.org/message-id/CAK3UJREBcyVBtr8D7vMfU=uDdkjXkrPnGcuy8erYB0tMfKe1LA@mail.gmail.com. От выделенного PostgreSQL shared_buffers зависит только одно - через какое время он упадет. Буферов меньше - работает дольше. Также в Changelog на http://wiki.openvz.org/Download/kernel/rhel6-testing/042stab078.21 есть упоминание об исправлении, которое, похоже, призвано решить эту проблему: "[ubc/shmem] full size is charged at creation now in order to return -ENOMEM in shmget(), not SIGBUS on an attempt to write into it (PCLIN-31867)". Вот только на 2.6.32-ovz-el-alt100 (которое основано на 042stab079.4) PostgreSQL точно так же падает с той же диагностикой... На данный момент PostgreSQL работает на HN. Без каких-либо проблем/сбоев/падений. Но очень хочется вернуть его в контейнер.... PS На всякий случай: cat /proc/bc/VEID/resources kmemsize 57991229 59351040 9223372036854775807 9223372036854775807 0 lockedpages 0 0 2048 2048 0 privvmpages 454308 462347 9223372036854775807 9223372036854775807 0 shmpages 43236 43237 9223372036854775807 9223372036854775807 0 numproc 206 219 1024 1024 0 physpages 149691 157290 524288 524288 0 vmguarpages 0 0 33792 9223372036854775807 0 oomguarpages 127680 133594 26112 9223372036854775807 0 numtcpsock 97 131 2048 2048 0 numflock 3 5 188 206 0 numpty 0 2 16 16 0 numsiginfo 0 6 256 256 0 tcpsndbuf 7036576 12626096 9223372036854775807 9223372036854775807 0 tcprcvbuf 10324296 15474008 9223372036854775807 9223372036854775807 0 othersockbuf 11560 83232 9223372036854775807 9223372036854775807 0 dgramrcvbuf 0 68864 9223372036854775807 9223372036854775807 0 numothersock 25 56 360 360 0 dcachesize 16529592 16561684 9223372036854775807 9223372036854775807 0 numfile 610 715 9312 9312 0 numiptent 20 20 128 128 0 swappages 2641 4644 262144 262144 0 -- WBR, Alex Moskalenko