Also, I didn't look at your network trace screen cap, but you should have
zero TCP retransmissions if you set your initial TCP window send window
small enough.
https://www.auvik.com/franklyit/blog/tcp-window-size/
On Fri, Jun 21, 2024, 07:53 Jeremy McMillan wrote:
> It could be netw
It could be network or persistent storage. What's the proportion of fast to
slow gets?
On Thu, Jun 20, 2024, 22:48 f cad wrote:
> here is a screenshot example
> [image: image.png]
>
> f cad 于2024年6月21日周五 11:45写道：
>
>> Hello, community:
>>
>> I have a cluster ,with three nodes.
>> I have two
This could work if you set up availability zones and use backup filters.
Then you could perform maintenance one entire AZ at a time. When running
during maintenance, your workload might exceed the capacity of the fraction
of server nodes remaining up, so beware that.
On Thu, May 30, 2024, 11:30
If backup partitions are available when a node is lost, we should not
expect lost partitions.
There is a lot more to this story than this thread explains, so for the
community: please don't follow this procedure.
https://ignite.apache.org/docs/latest/configuring-caches/partition-loss-policy
"A
Finding happiness is unfortunately never quite that simple.
1. Understand why the garbage collector cannot function with shorter
pauses.
(may require GC logging configuration to provide key details)
2. Identify priorities.
(ie. absolute minimal GC pauses for best latency
https://ignite.apache.org/docs/latest/key-value-api/transactions#deadlock-detection
The property you're asking about is for diagnostics to enable prevention of
future deadlocks. Turning it off is fine if you already know or can find
out another way what is deadlocked and why.
On Sat, Mar 23,
First, logging should be configured to at least WARN level if not INFO.
Ignite manages data internally at the page level. If you see errors about
pages, it is low, low level ignite problems. The next level up is
partitions. Errors involving partitions are mid low level ignite problems.
The next
2. If you want the Ignite cluster to be authoritative about caches, then
you should define them in the XML configuration or deploy your servers with
code which can look up the intended cache configurations and implement
them. If you have specific ideas how you would like to implement this,
maybe
To answer the OP question, maybe linear regression is sufficient for making
predictions in your data.
Ignite isn't really designed for exploratory data analysis, so it really
helps to understand the character of your data. Linear models are usually a
good place to start. Does a regression line
It might help if you address the Ignite community with a question about
Apache Ignite or GridGain skills and experience and needs. It might
demonstrate your skills if you participate in the community by answering
others' questions about Apache Ignite or GridGain, as it will establish
your
but not all, copies of the element where grid
> restarts do not correct the issue. This does not feel the same though.
>
> Raymond.
>
>
>
>
>
> On Thu, Nov 23, 2023 at 6:50 AM Jeremy McMillan <
> jeremy.mcmil...@gridgain.com> wrote:
>
>> I suspect a race condition
I suspect a race condition with async mode caches. This is a naive guess
though, as we don't have enough details. I'll assume this is a plea for
help in troubleshooting methodology and the question is really "what should
we look at next?"
The real answer comes from tracing the insert of element E
nio.GridDirectParser@7141a1d9, directMode=true],
> GridConnectionBytesVerifyFilter], accepted=true, markedForClose=false]]]
>
> On the client side I don't see any errors happening around that time, I
> have also searched for warnings, but nothing.
>
> I've seen this post where they
These errors look like something which does not speak Ignite binary
protocol is connecting and sending useless stuff to your Ignite cluster.
IgniteException: Invalid message type: 2057
Check the configuration of the client if the host generating this traffic
is known, and check firewalls or
e some suggestions about how can i confirm that it is a
> network problem?
> Best Regards.
>
> Jeremy McMillan 于2023年8月18日周五 20:39写道：
>
>> This is most likely to happen when Ignite is fast and the network is
>> slow. It's unclear what's happening when you experience this
This is most likely to happen when Ignite is fast and the network is slow.
It's unclear what's happening when you experience this error, so how to fix
it is also ambiguous.
You could try increasing direct buffer memory in Java options. If that's
not sufficient share more about your infrastructure
It would be appropriate for you to share any code and configuration to help
others recreate your system and the behavior you describe.
Without, many people could solve multiple problems, demonstrably, and yet
your problem is different enough that they are no help.
On Fri, Jul 14, 2023, 01:58
This will depend on how you are deploying your Spark workers. Whatever you
are doing to control Spark workers should be replicated to control startup
and shutdown of your Ignite nodes. Please start with the included ignite.sh
or ignite.bat scripts found in the bin folder of your Ignite
Python doesn't at this time go anywhere near Ignite CacheStore. You would
need to implement the CacheStore in Java or some other language which
compiles to JVM runtime/jar. There's a talk from the most recent summit on
using Groovy, if you want a higher level language than Java, but
theoretically
You will need to research the documentation on three subjects:
* Discovery
* Data distribution
* Client Cluster awareness
Much of what you seem to be asking is somewhat configurable, so the answer
is "it depends." Also, the question seems very broad, and you might benefit
from learning
Thanks for bringing this up!
https://ignite.apache.org/docs/latest/key-value-api/continuous-queries#events-delivery-guarantees
This sounds like you may have found a bug, but the details you've provided
are not sufficient to help others recreate and observe it for themselves,
and this effort
That's a big question, and it isn't clear whether there's a large or small
ratio of reads to writes between these microservices, for example. It isn't
clear what your latency tolerance is for these large transfers either.
This sounds like a big endeavor, and if there's money to be made, your best
Has this kind of benchmark ever been published for any p2p cluster
technology?
What questions would it answer if there were such benchmarks for Ignite?
Maybe this will help:
There is an established algorithm for estimating the amount of buffer space
necessary to keep a pipeline from stuttering
Java exception troubleshooting usually begins with an error message and a
stack trace. Can we get that added to your fine description of how you
found the error? We still don't know what error you found.
Also please provide your config, with secrets redacted, of course. Both the
details of the
These documentation pages should help.
https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations
https://ignite.apache.org/docs/latest/configuring-caches/atomicity-modes
On Tue, Feb 28, 2023 at 11:42 PM 38797715 <38797...@qq.com> wrote:
> hi,
>
> How to delete data of a
Have you tried tracing the workload on the 100% and 40% nodes for
comparison? There just isn't enough detail in your question to help predict
what should be happening with the cluster workload. For a starting point,
please identify your design goals. It's easy to get confused by advice that
seeks
The first step to begin debugging would be to configure logging, and reduce
the Ignite pods to one. Increase the logging details until you see
consistent positive indication of Ignite doing INSERT for each operation.
If the failures do not appear, gradually increase the workload and then the
pods
This seems to be at the level of a high quality bug report, and has enough
detail that a fix could probably be implemented and submitted as a PR
fairly easily. Are you familiar with the contributor process?
On Wed, Feb 1, 2023, 04:56 Айсина Роза Мунеровна
wrote:
> Hola!
> We run Ignite via
If your problem is simple and popular, then solutions will chase you.
Consider maybe you might be trying to do something really challenging that
doesn't have any off the shelf solutions.
You might need to approach this as a computer scientist and search for the
best fit, not just best available
ffinity key is to enable
> distributed JOIN?
>
> On 10 Jan 2023, at 10:48 PM, Jeremy McMillan
> wrote:
>
> Внимание: Внешний отправитель!
> Если вы не знаете отправителя - не открывайте вложения, не переходите по
> ссылкам, не пересылайте письмо!
>
> If you are only doing col
If you are only doing colocated joins, then there will be no runtime
overhead incurred by collecting distributed rows (colocated joins mean do
not try to join data that might be distributed across nodes), so there
might not be much difference in runtimes.
The difference between different affinity
You might want to watch the recording of the summit talk on Ignite 3
changes.
There is a major change around how binary column types and objects are
stored using Calcite.
On Thu, Nov 10, 2022, 15:10 tore yang via user
wrote:
> My cache has a column of type java map, the column name is "mymap".
ole excercise of configuring AZ as backup filter
> is because we want to handle AZ level failure.
>
> Anyway, thanks for inputs. Will figure out further steps
>
> On Sun, 6 Nov 2022, 20:55 Jeremy McMillan,
> wrote:
>
>> Don't configure 2 backups when you only have two failure
't this mean node 3 need 2X space as compared to node 1 and node2.
> Assuming backup partitions of node 3 would be equally distributed among
> other two nodes. They would need almost same space.
>
>
> On Tue, 1 Nov 2022, 23:30 Jeremy McMillan,
> wrote:
>
>>
>>
>>
er throw error if enough hardware is not present than risking
>> data unavailability issue during business activity
>>
>> 2. Why we want 3 copies of data. It's a design choice. We want to ensure
>> even if 2 nodes go down, we still have 3rd present to serve the data.
>>
e is not present than risking
> data unavailability issue during business activity
>
> 2. Why we want 3 copies of data. It's a design choice. We want to ensure
> even if 2 nodes go down, we still have 3rd present to serve the data.
>
> Hope I answered your question
>
> On Tue
This question is a design question.
What kids of fault states do you expect to tolerate? What is your failure
budget?
Why are you trying to make more than 2 copies of the data distribute across
only two failure domains?
Also "fail fast" means discover your implementation defects faster than
Using the AWS tutorial will get you a backup filter using this
implementation: ClusterNodeAttributeAffinityBackupFilter
There is logic to prevent a cascade of backup data onto survivor nodes in
case of multiple concurrent failures if you read the documentation.
Builder but noticed it creates multiple
> temporary caches with the same characteristics as upstream full training
> cache, i.e. distributed on all nodes. That's unnecessary in my case because
> I need the subset only temporarily on the worker node.
>
>
>
> On 30.09.22 01:08, Jeremy McMill
I share Stephen's curiosity about the use case. The best compromises are
sensitive to situation and outcomes.
Are you trying to cull training data into training, tuning, and validation
subsets?
Maybe there's a colocation approach that would suffice.
On Thu, Sep 29, 2022, 12:26 Thomas Kramer
I just read this, about hudi, and I can't see a use case for putting hudi
behind an Ignite write-through cache.
https://www.xenonstack.com/insights/what-is-hudi
Hudi seems to be a write accelerator for Spark on HDFS, primarily.
What would the expected outcome be if we assume the magic
Maybe it would be easier to start from OpenCV or something like that,
figure out how to get the processing pipeline MVP for the simplest use case
working, and then use Ignite as a data integration hub to scale out the
architecture?
My guess is the Redis example would have followed a similar
Have you followed all of the conventions in the .Net remote assembly
loading doc? Have you been able to follow the example given?
https://ignite.apache.org/docs/latest/net-specific/net-remote-assembly-loading
On Mon, Aug 29, 2022 at 9:08 AM Charlin S wrote:
> Hi,
> I have started .Net node on
https://github.com/apache/ignite/blob/da8a6bb4756c998aa99494d395752be96d841ec8/modules/core/src/main/java/org/apache/ignite/internal/processors/compress/FileSystemUtils.java#L45
Is Windows file storage supported for use with compression?
It isn't clear whether the Java FileStore spi supports the
44 matches
Mail list logo
