I can see how the GC errors will cause the world to stop spinning. The GC is itself not able to allocate memory which is not a great place to be in.
Sudheesh saw something similar in his branch. @Sudheesh is this possible we have a mem-leak in master? On Tue, Jun 14, 2016 at 11:37 AM, John Omernik <[email protected]> wrote: > This is what I have thus far... I can provide more complete logs on a one > on one basis. > > The cluster was completely mine, with fresh logs. I ran a CTAS query on a > large table that over 100 fields. This query works well in other cases, > however I was working with the Block size, both in MapR FS and Drill > Parquet. I had successfully tested 512m on each, this case was different. > Here are the facts in this setup: > > - No Compression in MapRFS - Using Standard Parquet Snappy Compression > - MapR Block Size 1024m > - Parquet Block size 1024m > - Query ends up disappearing in the profiles > > - The UI page listing bits only show 4 bits however 5 are running (node 03 > process is running, but no longer in the bit) > > - Error (copied below) from rest API > > - No output in STD out or STD error on node3. Only two nodes actually had > "Parquet Writing" logs. The other three on Stdout, did not have any > issues/errors/ > > - I have standard log files, gclogs, the profile.json (before it > disappeared), and the physical plan. Only some components that looked > possibly at issue included here > > - The Node 3 GC log shows a bunch of "Full GC Allocation Failures" that > take 4 seconds or more (When I've seen this in other cases, this time can > balloon to 8 secs or more) > > - The node 3 output log show some issues with really long RPC issues. > Perhaps the GCs prevent RPC communication and create a snowball loop > effect? > > > Other logs if people are interested can be provided upon request. I just > didn't want to flood the whole list with all the logs. > > > Thanks! > > > John > > > > > > > Rest Error: > > ./load_day.py 2016-05-09 > > Drill Rest Endpoint: https://drillprod.marathonprod.zeta:20000 > <https://drillprod.marathonprod.zeta.ctu-bo.secureworks.net:20000/> > > Day: 2016-05-09 > > /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: > InsecureRequestWarning: Unverified HTTPS request is being made. Adding > certificate verification is strongly advised. See: > https://urllib3.readthedocs.org/en/latest/security.html > > InsecureRequestWarning) > > Authentication successful > > Error encountered: 500 > > { > > "errorMessage" : "SYSTEM ERROR: ForemanException: One more more nodes > lost connectivity during query. Identified nodes were > [atl1ctuzeta03:20001].\n\n\n[Error Id: d7dd0120-f7c0-44ef-ac54-29c746b26354 > on atl1ctuzeta01 <http://atl1ctuzeta01.ctu-bo.secureworks.net:20001/ > >:20001" > > } > > > Possible issue in Node3 Log: > > > 2016-06-14 17:25:27,860 [289fc208-7266-6a81-73a1-709efff6c412:frag:1:90] > INFO o.a.d.e.w.f.FragmentStatusReporter - > 289fc208-7266-6a81-73a1-709efff6c412:1:90: State to report: RUNNING > > 2016-06-14 17:25:27,871 [289fc208-7266-6a81-73a1-709efff6c412:frag:1:70] > INFO o.a.d.e.w.fragment.FragmentExecutor - > 289fc208-7266-6a81-73a1-709efff6c412:1:70: State change requested > AWAITING_ALLOCATION --> RUNNING > > 2016-06-14 17:25:27,871 [289fc208-7266-6a81-73a1-709efff6c412:frag:1:70] > INFO o.a.d.e.w.f.FragmentStatusReporter - > 289fc208-7266-6a81-73a1-709efff6c412:1:70: State to report: RUNNING > > 2016-06-14 17:43:41,869 [BitServer-4] WARN > o.a.d.exec.rpc.control.ControlClient - Message of mode RESPONSE of rpc type > 1 took longer than 500ms. Actual duration was 4192ms. > > 2016-06-14 17:45:36,720 [CONTROL-rpc-event-queue] INFO > o.a.d.e.w.fragment.FragmentExecutor - > 289fc208-7266-6a81-73a1-709efff6c412:1:0: State change requested RUNNING > --> CANCELLATION_REQUESTED > > 2016-06-14 17:45:45,740 [CONTROL-rpc-event-queue] INFO > o.a.d.e.w.f.FragmentStatusReporter - > 289fc208-7266-6a81-73a1-709efff6c412:1:0: State to report: > CANCELLATION_REQUESTED > > 2016-06-14 17:46:15,318 [BitServer-3] WARN > o.a.d.exec.rpc.control.ControlServer - Message of mode REQUEST of rpc type > 6 took longer than 500ms. Actual duration was 55328ms. > > 2016-06-14 17:46:36,057 [CONTROL-rpc-event-queue] INFO > o.a.d.e.w.fragment.FragmentExecutor - > 289fc208-7266-6a81-73a1-709efff6c412:1:5: State change requested RUNNING > --> CANCELLATION_REQUESTED > > 2016-06-14 17:46:44,620 [CONTROL-rpc-event-queue] INFO > o.a.d.e.w.f.FragmentStatusReporter - > 289fc208-7266-6a81-73a1-709efff6c412:1:5: State to report: > CANCELLATION_REQUESTED > > 2016-06-14 17:47:01,393 [BitServer-3] WARN > o.a.d.exec.rpc.control.ControlServer - Message of mode REQUEST of rpc type > 6 took longer than 500ms. Actual duration was 29781ms. > > 2016-06-14 17:47:09,463 [CONTROL-rpc-event-queue] INFO > o.a.d.e.w.fragment.FragmentExecutor - > 289fc208-7266-6a81-73a1-709efff6c412:1:10: State change requested RUNNING > --> CANCELLATION_REQUESTED > > 2016-06-14 17:47:26,967 [CONTROL-rpc-event-queue] INFO > o.a.d.e.w.f.FragmentStatusReporter - > 289fc208-7266-6a81-73a1-709efff6c412:1:10: State to report: > CANCELLATION_REQUESTED > > 2016-06-14 17:47:55,593 [BitServer-3] WARN > o.a.d.exec.rpc.control.ControlServer - Message of mode REQUEST of rpc type > 6 took longer than 500ms. Actual duration was 46130ms. > > 2016-06-14 17:48:04,497 [CONTROL-rpc-event-queue] INFO > o.a.d.e.w.fragment.FragmentExecutor - > 289fc208-7266-6a81-73a1-709efff6c412:1:15: State change requested RUNNING > --> CANCELLATION_REQUESTED > > 2016-06-14 17:48:12,742 [BitServer-4] WARN > o.a.d.exec.rpc.control.ControlClient - Message of mode RESPONSE of rpc type > 1 took longer than 500ms. Actual duration was 4236ms. > > 2016-06-14 17:48:42,328 [CONTROL-rpc-event-queue] INFO > o.a.d.e.w.f.FragmentStatusReporter - > 289fc208-7266-6a81-73a1-709efff6c412:1:15: State to report: > CANCELLATION_REQUESTED > > 2016-06-14 17:49:36,351 [BitServer-4] WARN > o.a.d.exec.rpc.control.ControlClient - Message of mode RESPONSE of rpc type > 1 took longer than 500ms. Actual duration was 4260ms. > > 2016-06-14 17:49:36,351 [BitServer-3] WARN > o.a.d.exec.rpc.control.ControlServer - Message of mode REQUEST of rpc type > 6 took longer than 500ms. Actual duration was 91854ms. > > 2016-06-14 17:50:35,273 [CONTROL-rpc-event-queue] INFO > o.a.d.e.w.fragment.FragmentExecutor - > 289fc208-7266-6a81-73a1-709efff6c412:1:20: State change requested RUNNING > --> CANCELLATION_REQUESTED > > 2016-06-14 17:50:39,322 [289fc208-7266-6a81-73a1-709efff6c412:frag:1:15] > INFO o.a.d.e.w.fragment.FragmentExecutor - > 289fc208-7266-6a81-73a1-709efff6c412:1:15: State change requested > CANCELLATION_REQUESTED --> FAILED > > 2016-06-14 17:50:51,546 [CONTROL-rpc-event-queue] INFO > o.a.d.e.w.f.FragmentStatusReporter - > 289fc208-7266-6a81-73a1-709efff6c412:1:20: State to report: > CANCELLATION_REQUESTED > > 2016-06-14 17:51:36,905 [BitServer-4] WARN > o.a.d.exec.rpc.control.ControlClient - Message of mode RESPONSE of rpc type > 1 took longer than 500ms. Actual duration was 4426ms. > > 2016-06-14 17:52:30,805 [BitServer-3] WARN > o.a.d.exec.rpc.control.ControlServer - Message of mode REQUEST of rpc type > 6 took longer than 500ms. Actual duration was 98767ms. > > 2016-06-14 17:52:47,042 [BitServer-4] WARN > o.a.d.exec.rpc.control.ControlClient - Message of mode RESPONSE of rpc type > 1 took longer than 500ms. Actual duration was 12041ms. > > Possible issues in Node3 gclog: > > > 1819.137: [Full GC (Allocation Failure) 23G->23G(24G), 4.0657064 secs] > > 1823.205: [GC concurrent-mark-abort] > > 1823.221: [GC pause (G1 Evacuation Pause) (young)-- 23G->23G(24G), > 0.0382934 secs] > > 1823.271: [GC pause (G1 Evacuation Pause) (young) (initial-mark) > 23G->23G(24G), 0.0250215 secs] > > 1823.296: [GC concurrent-root-region-scan-start] > > 1823.296: [GC concurrent-root-region-scan-end, 0.0000105 secs] > > 1823.296: [GC concurrent-mark-start] > > 1823.308: [Full GC (Allocation Failure) 23G->23G(24G), 4.3719713 secs] > > 1827.694: [GC pause (G1 Evacuation Pause) (young)-- 23G->23G(24G), > 0.0312666 secs] > > 1827.727: [GC concurrent-mark-abort] > > 1827.735: [GC pause (G1 Evacuation Pause) (young) 23G->23G(24G), 0.0212359 > secs] > > 1827.766: [Full GC (Allocation Failure) 23G->23G(24G), 3.9308980 secs] > > 1831.710: [GC pause (G1 Evacuation Pause) (young)-- 23G->23G(24G), > 0.0298229 secs] > > 1831.750: [GC pause (G1 Evacuation Pause) (young) (initial-mark) > 23G->23G(24G), 0.0268410 secs] > > 1831.777: [GC concurrent-root-region-scan-start] > > 1831.777: [GC concurrent-root-region-scan-end, 0.0000212 secs] > > 1831.777: [GC concurrent-mark-start] > > 1831.789: [Full GC (Allocation Failure) 23G->23G(24G), 3.9250410 secs] > > > > On Mon, Jun 13, 2016 at 6:54 PM, John Omernik <[email protected]> wrote: > > > Yep, I will create all clean logs tomorrow run the query that caused it. > > Thanks. John > > > > > > On Monday, June 13, 2016, Parth Chandra <[email protected]> wrote: > > > >> Yes, we can discuss this on the hangout. > >> You're right, there are two issues - > >> Limiting memory usage to a maximum limit should be the goal of every > >> component. We are not there yet with Drill though. > >> Getting an Out of Memory Error and having the Drillbit become > >> unresponsive is something we should rarely see as either the Drill > >> allocator or the JVM successfully catch the condition. Can you grep your > >> logs so we can see if that indeed is what happened? > >> > >> > >> > >> On Mon, Jun 13, 2016 at 4:27 PM, John Omernik <[email protected]> wrote: > >> > >> > I'd like to talk about that on the hangout. Drill should do better at > >> > failing with a clean oom error rather then having a bit go > unresponsive. > >> > Can just that bit be restarted to return to a copacetic state? As an > >> admin, > >> > if this is the case, how do I find this bit? > >> > > >> > Other than adding RAM, are there any query tuning settings that could > >> help > >> > prevent the unresponsive bit? ( I see this as two issues, the memory > >> > settings for the 1024m block size CTAS and the how can we prevent a > bit > >> > from going unresponsive? ) > >> > On Jun 13, 2016 6:19 PM, "Parth Chandra" <[email protected]> > wrote: > >> > > >> > The only time I've seen a drillbit get unresponsive is when you run > out > >> of > >> > Direct memory. Did you see any 'Out of Memory Error' in your logs? If > >> you > >> > see those then you need to increase the Direct memory setting for the > >> JVM. > >> > ( DRILL_MAX_DIRECT_MEMORY in drill-env.sh) > >> > > >> > > >> > > >> > > >> > On Mon, Jun 13, 2016 at 4:10 PM, John Omernik <[email protected]> > wrote: > >> > > >> > > The 512m block size worked. My issue with the 1024m block size was > on > >> > the > >> > > writing using a CTAS.... that's where my nodes got into a bad > >> > state....thus > >> > > I am wondering what setting on drill would be the right setting to > >> help > >> > > node memory pressures on a CTAs using 1024m block size > >> > > On Jun 13, 2016 6:06 PM, "Parth Chandra" <[email protected]> > >> wrote: > >> > > > >> > > In general, you want to make the Parquet block size and the HDFS > block > >> > size > >> > > the same. A Parquet block size that is larger than the HDFS block > size > >> > can > >> > > split a Parquet block ( i.e. row_group ) across nodes and that will > >> > > severely affect performance as data reads will no longer be local. > >> 512 MB > >> > > is a pretty good setting. > >> > > > >> > > Note that you need to ensure the Parquet block size in the source > file > >> > > which (maybe) was produced outside of Drill. So you will need to > make > >> the > >> > > change in the application used to write the Parquet file. > >> > > > >> > > If you're using Drill to write the source file as well then, of > >> course, > >> > the > >> > > block size setting will be used by the writer. > >> > > > >> > > If you're using the new reader, then there is really no knob you > have > >> to > >> > > tweak. Is parquet-tools able to read the file(s)? > >> > > > >> > > > >> > > > >> > > On Mon, Jun 13, 2016 at 1:59 PM, John Omernik <[email protected]> > >> wrote: > >> > > > >> > > > I am doing some performance testing, and per the Impala > >> documentation, > >> > I > >> > > am > >> > > > trying to use a block size of 1024m in both Drill and MapR FS. > >> When I > >> > > set > >> > > > the MFS block size to 512 and the Drill (default) block size I saw > >> some > >> > > > performance improvements, and wanted to try the 1024 to see how it > >> > > worked, > >> > > > however, my query hung and I got into that "bad state" where the > >> nodes > >> > > are > >> > > > not responding right and I have to restart my whole cluster (This > >> > really > >> > > > bothers me that a query can make the cluster be unresponsive) > >> > > > > >> > > > That said, what memory settings can I tweak to help the query > work. > >> > This > >> > > is > >> > > > quite a bit of data, a CTAS from Parquet to Parquet, 100-130G of > >> data > >> > per > >> > > > data (I am doing a day at a time), 103 columns. I have to use > the > >> > > > "use_new_reader" option due to my other issues, but other than > that > >> I > >> > am > >> > > > just setting the block size on MFS and then updating the block > size > >> in > >> > > > Drill, and it's dying. Since this is a simple CTAS (no sort) which > >> > > settings > >> > > > can be beneficial for what is happening here? > >> > > > > >> > > > Thanks > >> > > > > >> > > > John > >> > > > > >> > > > >> > > >> > > > > > > -- > > Sent from my iThing > > >
