Just like any other piece of software, Orchids consumes memory. \u00a0Monitoring signatures can involve using a growing amount of memory over time.<\/p>\n
You can get some information on memory consumption by running run Orchids with the\u00a0 However, machines have finite memory. \u00a0If Orchids just ran its algorithm blindly, it would eventually use up all the memory the machine has. \u00a0An attacker, knowing that, could just feed events to the machine so that Orchids would consume as much memory as possible, leading to a so-called denial-of-service attack.<\/p>\n Orchids has two ways to mitigate that.<\/p>\n Critical memory mode does a lot of nasty things. \u00a0By deallocating index tables, Orchids is slowed down. \u00a0By killing threads,\u00a0 some attacks will go undetected. \u00a0However, this is better than just letting Orchids abort\u2014and no longer detect anything.<\/p>\n The strategy that Orchids uses to kill threads in critical memory mode is experimental, and subject to change. \u00a0The risk is that an attacker might know that strategy, and exploit it so as to hide some attacks to Orchids. \u00a0Keeping the strategy secret makes no sense, if only because the Orchids source is public.<\/p>\n For now, the strategy is as follows: kill the most recent threads. \u00a0That is it.<\/p>\n The important point is that that strategy does not kill the threads that monitor long-standing attack candidates. \u00a0The opposite strategy, killing the oldest threads, would be all too easy to exploit for attackers: start some activity that Orchids can monitor, then drown Orchids into a flow of events, so as to make sure to induce a critical memory situation: if Orchids killed the oldest threads, the attacker could be sure he could proceed undetected.<\/p>\n","protected":false},"excerpt":{"rendered":" Just like any other piece of software, Orchids consumes memory. \u00a0Monitoring signatures can involve using a growing amount of memory over time. You can get some information on memory consumption by running run Orchids with the\u00a0-v1 flag. \u00a0In that case, Orchids will tell you what signatures are costly in terms of number of threads created. … Continue reading Low memory, and the rainy day fund<\/span> -v1<\/code> flag. \u00a0In that case, Orchids will tell you what signatures are costly in terms of number of threads created. \u00a0A signature that creates\u00a0n<\/em> threads (at most) after reading\u00a0n<\/em> events can be expected to also use memory proportional to the number of events.<\/p>\n\n
MaxMemorySize<\/code> directive in orchids.conf<\/a>. \u00a0Orchids will never consume more that the memory you set this way.<\/li>\nMaxMemorySize<\/code> directive, there is simply no memory left to do any work, and Orchids would in principle abort.
\nThe idea of the rainy day fund is as follows. \u00a0On start up, Orchids preallocates a dummy block of memory. \u00a0The size of that block of memory is specified by the RainyDayFund<\/code> directive\u00a0in orchids.conf<\/a>.
\nWhenever Orchids reaches its memory limit, it will enter a so-called low memory mode<\/em>. \u00a0In that mode, Orchids will starting eating up some memory from the rainy day fund, while measuring how much memory each thread will consume.
\nIf Orchids ever consumes more than a fixed amount of the rainy day fund (fixed to 75% for now), then it enters\u00a0critical memory mode<\/em>. \u00a0In that mode, Orchids deallocates the index tables that help it execute fast, and kills enough threads to recuperate enough memory. \u00a0Once that is done, it reallocates as much of the rainy day fund as it can, attempting to go back to normal mode.<\/li>\n<\/ul>\n