Thanks Arie. I have already tried that yesterday and did not help.
I have removed unnecessary TCP input, and I don't have any NettyTransport
exceptions now.
I still have problem with RecvQ in peaks (as seen in netstat) which should
be related to slow processing.
Do you have any benchmark data
Thanks for clarifications. I think I found a workaround for my issue:
source:staging* AND message:(Missing AND assetId*)
which is not beautiful but does it's job.
Thanks for your time
On Wednesday, January 28, 2015 at 1:45:37 PM UTC+1, Arie wrote:
Marciej,
THis is exactly as I told you.
I doubt that this is a graylog issue because it tries to have Netty set the
correct size which fails.
I don't know centos well enough to tell if there's anything special (I
doubt it) but there's also tcp_rmem and tcp_moderate_rcvbuf to check.
Pretty sure there are no ulimits in place since this
Hello Kay,
graylog2-server is running as root, on CentOS 6 minimal that does not have
additional limits.
I've noticed that this exception is shown only with TCP input..so there may
be TCP limitation. I haven't tweaked TCP since we use TCP only for
Keepalived HTTP checks, and UDP for logs
Not really because when you do
source:hostname Missing assetId*
you are doing OR and not AND. So all messages containing a hostname OR a
Missing assetId* is being searched.
When you add AND then no messages are found when using a wildcard.
On Wednesday, January 28, 2015 at 11:41:51 AM
I don't think that information is related to the issue you reported, at least
if I understood it correctly.
As far as I know, we always use query string queries for searching. Anyway,
when you type the term assetId* (without quotes), your wildcard gets analysed
correctly or it should in most
Hello,
As far as I know, it is not possible to use an exact phrase (a search term
enclosed in quotation marks) with wildcards inside in Elasticsearch. The
wildcard will be simply ignored. If you only want to check that your query
matches both Missing assetId and Missing assetIds, this is what
Marciej,
THis is exactly as I told you.
For this type of query you have to specify a default_field AND your
contend* search query.
The default field could be the input of your messages for example, or any
other field that is relied to your search.
On Wednesday, January 28, 2015 at 1:24:36
An the second option I gave, does that work?
We experience exactly the same thing.
On Tuesday, January 27, 2015 at 2:37:50 PM UTC+1, Maciej Strömich wrote:
Hi,
I know that allow_leading_wildcard_searches and it's used to search for
terms like *something, and I know that it can cause
Maybe this can be helpfull to you:
https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Web_Platform/5/html/Administration_And_Configuration_Guide/jgroups-perf-udpbuffer.html
or this for more advanced network tuning:
https://wwwx.cs.unc.edu/~sparkst/howto/network_tuning.php
hth,,
This is not exactly true, or I'm misreading something in the elasticsearch
docs.
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-query-string-query.html
analyze_wildcard - By default, wildcards terms in a query string are not
analyzed. By setting this value to
O I forgot (:-
Are vmware-tools installed? We recently found some systems that where
forgotten, and that has more impact than foreseen.
Op woensdag 28 januari 2015 21:25:11 UTC+1 schreef Arie:
Petar,
we are running on bare metal, with a low load. Tested to 10k messages with
the http test
Petar,
we are running on bare metal, with a low load. Tested to 10k messages with
the http test input,
with everything on one (test)server and running well.
I can tell you that in our production systems in our private/local cloud we
are encountering severe
network/disk related problems with
13 matches
Mail list logo
