Thanks Andrey. I checked both files, and there's nothing of internet. This is my complete kern.log file for example:
Apr 8 10:10:04 localhost kernel: [1282413.300235] audit_printk_skb: 24 callbacks suppressed Apr 8 10:10:04 localhost kernel: [1282413.300241] type=1400 audit(1460103004.823:19): apparmor="STATUS" operation="profile_replace" parent=21949 profile="unconfined" name="/usr/sbin/mysqld" pid=21956 comm="apparmor_parser" Apr 8 10:11:27 localhost kernel: [1282496.440652] type=1400 audit(1460103087.963:20): apparmor="STATUS" operation="profile_replace" parent=22456 profile="unconfined" name="/usr/sbin/mysqld" pid=22460 comm="apparmor_parser" and my /var/log/syslog also doesn't contain anything exciting.... On Sat, Apr 9, 2016 at 3:40 PM, Andrey Lomakin <[email protected]> wrote: > Hi Erik, > Could you inspect following files /var/log/syslog and /var/log/kern.log > using grep for example grep -i orient /var/log/kern.log and send us > results. > > > On Sat, Apr 9, 2016 at 1:35 AM Erik Pragt <[email protected]> wrote: > >> Thanks! I'm using Ubuntu, I think 14.x >> >> On 09 Apr 2016, at 00:55, Andrey Lomakin <[email protected]> >> wrote: >> >> Hi Erik, >> If system error happens (that is the only reason which we can think why >> it was shutted down without any exceptions) your OS log should contain >> information about >> that error. >> Which OS do you use ? >> >> On Fri, Apr 8, 2016 at 3:48 PM Erik Pragt <[email protected]> wrote: >> >>> Hi Luca, >>> >>> I'm sorry, that was an error on my part: I changed that after the crash, >>> before the crash it was on a very low setting, around 400. I'll change it >>> back anyway! >>> >>> >>> Erik >>> >>> On 08 Apr 2016, at 20:10, Luca Garulli <[email protected]> wrote: >>> >>> Hi Erik, >>> Do you have 2GB of RAM on that server? if this is the case, you cannot >>> have 8GB of RAM for the Diskcache: >>> >>> -Dstorage.diskCache.bufferSize=8192 >>> >>> So this must be the reason. This is the formula: >>> >>> diskcache + heap < available ram >>> >>> So with 1,5GB of free RAM, try these settings: >>> >>> MAXHEAP=-Xmx700m and -Dstorage.diskCache.bufferSize=512 >>> >>> Best Regards, >>> >>> Luca Garulli >>> >>> Founder & CEO >>> OrientDB <http://orientdb.com/> >>> >>> >>> >>> On 8 April 2016 at 10:14, Erik Pragt <[email protected]> wrote: >>> >>>> Hi Luca, >>>> >>>> Thanks for your response. >>>> >>>> - I'm running on Digital Ocean, 2 core 2 gig version. >>>> - Around 1500 mb. >>>> - What kind of swap do you mean? On an OS level? >>>> >>>> Thanks for the help! >>>> Erik >>>> >>>> On Friday, April 8, 2016 at 5:39:06 PM UTC+10, l.garulli wrote: >>>>> >>>>> Hi Erik, >>>>> >>>>> If OrientDB dies with no log, it means the OS killed it. The most >>>>> common reason is the out of memory. >>>>> >>>>> Look at: >>>>> http://stackoverflow.com/questions/726690/who-killed-my-process-and-why >>>>> >>>>> A few questions for you: >>>>> >>>>> - How much physical RAM do you have on that server and >>>>> - How much is available before you start OrientDB server? >>>>> - Did you configure any swap for your server? >>>>> >>>>> >>>>> Best Regards, >>>>> >>>>> Luca Garulli >>>>> Founder & CEO >>>>> OrientDB <http://orientdb.com/> >>>>> >>>>> >>>>> On 8 April 2016 at 09:34, Luigi Dell'Aquila <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Erik, >>>>>> >>>>>> It's hard to give you an answer here, this is the first report we >>>>>> have from a system that crashes without emitting any logs at all. >>>>>> In other cases, when we had an unexpected crash with few information, >>>>>> it was because of some OS related procedures (eg. process kill under >>>>>> heavy >>>>>> load), but also in that case we had a log stating that the server was >>>>>> killed. >>>>>> >>>>>> Could you please share your logs? Maybe we will find some hints in >>>>>> the history >>>>>> >>>>>> Thanks >>>>>> >>>>>> Luigi >>>>>> >>>>>> >>>>>> 2016-04-08 2:18 GMT+02:00 Erik Pragt <[email protected]>: >>>>>> >>>>>>> Btw, running OrientDB 2.1.9. >>>>>>> >>>>>>> >>>>>>> On Friday, April 8, 2016 at 10:05:33 AM UTC+10, Erik Pragt wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> As the question title suggests, our OrientDB database crashed >>>>>>>> today. We got notified by our monitoring server that our sites aren't >>>>>>>> accepting any requests anymore, which was quickly traced to OrientDB >>>>>>>> being >>>>>>>> unavailable, i.e., not running anymore. >>>>>>>> >>>>>>>> However, when checking the logs (orientdb.err/orientdb.log), there >>>>>>>> was no indication at all of any crash. What can I do to investigate >>>>>>>> this >>>>>>>> issue, and, even better, prevent OrientDB from crashing again? This >>>>>>>> isn't >>>>>>>> the first time OrientDB crashes, but usually it's with an OutOfMemory >>>>>>>> exception, which we fixed(?) by giving it more memory. Currently, the >>>>>>>> DB >>>>>>>> hardly does anything (1 request per 10 seconds?), and we're a bit >>>>>>>> worried >>>>>>>> that once we do get some requests, that OrientDB might crash more >>>>>>>> often. >>>>>>>> >>>>>>>> Our current settings to run OrientDB look like this: >>>>>>>> >>>>>>>> ORIENTDB_SETTINGS="-Dprofiler.enabled=true" >>>>>>>> JAVA_OPTS_SCRIPT="-Djna.nosys=true -XX:+HeapDumpOnOutOfMemoryError >>>>>>>> -Djava.awt.headless=true -Dfile.encoding=UTF8 -Drhino.opt.level=9" >>>>>>>> >>>>>>>> # ORIENTDB MAXIMUM HEAP. USE SYNTAX -Xmx<memory>, WHERE <memory> >>>>>>>> HAS THE TOTAL MEMORY AND SIZE UNIT. EXAMPLE: -Xmx512m >>>>>>>> MAXHEAP=-Xmx1024m >>>>>>>> # ORIENTDB MAXIMUM DISKCACHE IN MB, EXAMPLE, ENTER >>>>>>>> -Dstorage.diskCache.bufferSize=8192 FOR 8GB >>>>>>>> #MAXDISKCACHE="" >>>>>>>> MAXDISKCACHE="-Dstorage.diskCache.bufferSize=8192" >>>>>>>> >>>>>>>> If we need to provide some more information, please let me know. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> >>>>>>>> Erik Pragt >>>>>>>> >>>>>>> -- >>>>>>> >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "OrientDB" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "OrientDB" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "OrientDB" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> >>> --- >>> >>> You received this message because you are subscribed to a topic in the >>> Google Groups "OrientDB" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/orient-database/Xith1NqSX0k/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "OrientDB" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> Best regards, >> Andrey Lomakin, R&D lead. >> OrientDB Ltd >> >> twitter:@Andrey_Lomakin linkedin:https://ua.linkedin.com/in/andreylomakin >> >> -- >> >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "OrientDB" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/orient-database/Xith1NqSX0k/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OrientDB" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > Best regards, > Andrey Lomakin, R&D lead. > OrientDB Ltd > > twitter:@Andrey_Lomakin linkedin:https://ua.linkedin.com/in/andreylomakin > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "OrientDB" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/orient-database/Xith1NqSX0k/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
