Thanks! I've already done it, it helped and post graphs (today) for you to interpret them. Earlier I used Hypertable.RangeServer.MemoryLimit.Percentage=20 or 30 or 40 and it didn't help me at all. Now I use Hypertable.RangeServer.MemoryLimit=1900Mb (see my post today with graphs)
I think, the reason is when we have no limit or high limit, RangeServer use ALL memory (see graph "Block Cache Max Memory"), even if it is fill at 95% or more. On Thursday, August 16, 2012 4:04:31 PM UTC+3, Christoph Rupp wrote: > > Hi Kenny, > > can you try reducing the memory usage of the RangeServer? By default the > RangeServer uses 60% of the memory. > > There are two properties: > > Hypertable.RangeServer.MemoryLimit or > Hypertable.RangeServer.MemoryLimit.Percentage. > > You can use either of them. > > Bye > Christoph > > 2012/8/16 Kenny F. <[email protected] <javascript:>> > >> >Is it possible that there is some other process (or set of processes) on >> the machine at the time of the crash that is using up all virtual memory? >> I don't think so. >> First, I have 2 memory greed processes only: Hypertable and Apache. >> Second, I didn't change the environment. And restarting the system didn't >> solve the issue. >> Third, RangeServer didn't live more then several hours. >> And I don't remember, when RangeServer crashes immediately. >> >> >> On Thursday, August 16, 2012 3:02:39 PM UTC+3, Doug Judd wrote: >> >>> Hi Kenny, >>> >>> One other thought. Is it possible that there is some other process (or >>> set of processes) on the machine at the time of the crash that is using up >>> all virtual memory? Try running 'free' at regular intervals during your >>> test to see if the system is running out of swap space. >>> >>> - Doug >>> >>> On Tue, Aug 14, 2012 at 6:51 AM, Kenny F. <[email protected]> wrote: >>> >>>> 0.9.6.0.95b0abc tracks: >>>> >>>> # screen -r >>>> >>>> >>>> Program received signal SIGABRT, Aborted. >>>> [Switching to Thread 0x99ec9b70 (LWP 15640)] >>>> 0xffffe424 in __kernel_vsyscall () >>>> >>>> >>>> # where >>>> >>>> #0 0xffffe424 in __kernel_vsyscall () >>>> #1 0xb7b28781 in raise () from /lib/i686/cmov/libc.so.6 >>>> #2 0xb7b2bbb2 in abort () from /lib/i686/cmov/libc.so.6 >>>> #3 0xb7d34959 in __gnu_cxx::__verbose_**terminate_handler() () from >>>> /opt/hypertable/0.9.6.0.**95b0abc/lib/libstdc++.so.6 >>>> #4 0xb7d32865 in ?? () from /opt/hypertable/0.9.6.0.** >>>> 95b0abc/lib/libstdc++.so.6 >>>> #5 0xb7d328a2 in std::terminate() () from /opt/hypertable/0.9.6.0.** >>>> 95b0abc/lib/libstdc++.so.6 >>>> #6 0xb7d329da in __cxa_throw () from /opt/hypertable/0.9.6.0.** >>>> 95b0abc/lib/libstdc++.so.6 >>>> *#7 0xb7d33033 in operator new(unsigned int) () from /opt/hypertable/ >>>> 0.9.6.0.95b0abc/lib/libstdc++.so.6 >>>> #8 0xb7d3311d in operator new[](unsigned int) () from /opt/hypertable/ >>>> 0.9.6.0.95b0abc/lib/libstdc++.so.6* >>>> #9 0x0869ef81 in Hypertable::DynamicBuffer::**grow (this=0x99ec7ff4, >>>> new_size=1000004, nocopy=false) at /root/src/hypertable/src/cc/** >>>> Common/DynamicBuffer.h:120 >>>> #10 0x0869f095 in Hypertable::DynamicBuffer::**reserve >>>> (this=0x99ec7ff4, len=1000004, nocopy=false) at >>>> /root/src/hypertable/src/cc/ >>>> **Common/DynamicBuffer.h:72 >>>> #11 0x08773887 in Hypertable::FillScanBlock (scanner=..., dbuf=..., >>>> buffer_size=1000000) at /root/src/hypertable/src/cc/** >>>> Hypertable/RangeServer/**FillScanBlock.cc:104 >>>> #12 0x086628c1 in Hypertable::RangeServer::**create_scanner >>>> (this=0x8c95460, cb=0x99ec92a8, table=0x99ec929c, range_spec=0x99ec9290, >>>> scan_spec=0x99ec9200, cache_key=0x99ec9278) >>>> at /root/src/hypertable/src/cc/**Hypertable/RangeServer/** >>>> RangeServer.cc:1371 >>>> #13 0x087d53e6 in Hypertable::**RequestHandlerCreateScanner::**run >>>> (this=0x331d9840) at /root/src/hypertable/src/cc/** >>>> Hypertable/RangeServer/**RequestHandlerCreateScanner.**cc:59 >>>> #14 0x0862debc in Hypertable::ApplicationQueue::**Worker::operator() >>>> (this=0x8c83cf8) at /root/src/hypertable/src/cc/** >>>> AsyncComm/ApplicationQueue.h:**172 >>>> #15 0x0862df18 in boost::detail::thread_data<** >>>> Hypertable::ApplicationQueue::**Worker>::run (this=0x8c83c28) at >>>> /usr/local/include/boost/**thread/detail/thread.hpp:61 >>>> #16 0xb7ebfe68 in thread_proxy () from /opt/hypertable/0.9.6.0.** >>>> 95b0abc/lib/libboost_thread.**so.1.44.0 >>>> #17 0xb7e05955 in start_thread () from /lib/i686/cmov/libpthread.so.0 >>>> #18 0xb7bca5ee in clone () from /lib/i686/cmov/libc.so.6 >>>> >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Hypertable Development" group. >>>> To view this discussion on the web visit https://groups.google.com/d/** >>>> msg/hypertable-dev/-/**mV9fO9SeT_IJ<https://groups.google.com/d/msg/hypertable-dev/-/mV9fO9SeT_IJ> >>>> . >>>> >>>> To post to this group, send email to hyperta...@googlegroups.**com. >>>> To unsubscribe from this group, send email to hypertable-de...@** >>>> googlegroups.com. >>>> >>>> For more options, visit this group at http://groups.google.com/** >>>> group/hypertable-dev?hl=en<http://groups.google.com/group/hypertable-dev?hl=en> >>>> . >>>> >>> >>> >>> >>> -- >>> Doug Judd >>> CEO, Hypertable Inc. >>> >>> > -- You received this message because you are subscribed to the Google Groups "Hypertable Development" group. To view this discussion on the web visit https://groups.google.com/d/msg/hypertable-dev/-/CWqXo6VjsGQJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/hypertable-dev?hl=en.
