Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
Currently using boltdb for storing various entries in the bucket.
How can I use goroutines and channels in reading and updating in the db?
Generally, yes you can, provided you pay attention to the following points:
all accesses should be done in their own transactions. Transactions should not be shared between goroutines (whether they are read-only or read-write).
boltdb only tolerates one writer at a given point in time. If multiple concurrent transactions try to write at the same time, they will be serialized. The consistency of the database is guaranteed, but it has an impact on the performance, since write operations cannot be parallelized.
read-only transactions are executed concurrently (and potentially parallelized).
open only one transaction in a given goroutine at the same time to avoid deadlock situations.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
This post was edited and submitted for review 1 year ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
When should you consider disabling auto-suspend for a Virtual Warehouse?
A. When users will be using compute at different times throughout a 24/7 period
B. When managing a steady workload
C. When the compute must be available with no delay or lag time
D. When you don’t want to have to manually turn on the Warehouse each time a user needs it
If we have to choose 2 options "B" is perfect but how about from "C" or "D" ?
The most common reason to disable auto-suspend is in situations where you don't want to lose the cache that exists on the warehouse, which would add additional query time to the first few queries that are executed after a warehouse resumes. In essence, when query time is critical and must be consistent, you'd potentially want to disable auto-suspend and allow the warehouse to stay up and running (either 24/7 or during a specified time period - using a task to suspend or resume the warehouse explicitly).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I need to reduce the cost of servers.
the current server has the application
web, the database. the technical characteristics in general are
5tb
16 cpus
30gb ram
the current application does not exceed 100 users per day, the database weighs approx 30 GB. for these reasons the current server expense seems too much to me. I checked in digital ocean droplet and proposed to have the web application in an 8 CPUs, 16 GB ram, 1tb. the database in a 4 CPUs, 16 GB ram, 240 GB solid disk. But how can I know if what I am proposing is correct? to make the server change. thanks for your help.
Nobody can tell you the size of equipment you would use because this is totally dependent upon your application and how it is used.
For example, some applications are CPU-heavy (doing video processing), some require a lot of memory (keeping lots of data accessible), some are disk-dependent (doing database transactions). The "shape" of every application is different. Your application might be able to take advantage of multiple CPUs, or perhaps it is only using some of them.
Also, how users interact with every application is different. People use Facebook different to a banking app, different to a gaming website. If your 100 users are all in the same timezone, then usage will be different to having them spread around the world.
The only way to know what specification is require is either to monitor live traffic on the website and observe how CPU, RAM and disk is used, or simulate levels of traffic to reproduce what users typically do on the website and then measure the behaviour of the system.
Then there is the question of reliability. Consider whether you willing to run everything on one server, where the app might be unavailable if something goes wrong. Or perhaps you need high availability to ensure uptime, but at a greater cost.
Since you appear to be cost-conscious, I would recommend:
Monitor your current system (CPU, RAM, network, disk) during periods of normal usage.
If some aspects seem over-provisioned, then reduce them (eg if CPU never goes above 40%, reduce it). Check whether all CPUs are being used.
Use some form of continual monitoring to notify you when the application is not behaving as desired.
Keep log files to allow you to deep-dive into what might be causing the application problems.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have a number of nodes each owning a subset of a large pool of physical resources. Each node only handles it's own resources but needs to do so based on the state of all resources in the pool.
A node only updates the state of it's own resources but listens to state changes of all the others.
When a node dies (process terminated, crash, power loss,...) those physical resources die with it and the other nodes must discard them ASAP.
Now i would do this with a distributed replicated cache (so nodes can read the local replicas for performance), but how to "clear" deceases entries (the owning node can't do it).
Standard answer seems to be Expiry policy = map entry gets X seconds to live without update, then gone. Problem is, if you are thinking in the 100.000 range of resources and 100 nodes, that is a LOT of updates to send everywhere for NOT changing state. Not to mention the work to update each entry before the timeout and discard these updates in the other nodes.
Any better way of doing this?
Subscribe to EVT_NODE_LEFT via IgniteEvents
Find related entries via SqlQuery or ScanQuery and remove them
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
For pubsub topics with number of messages in the range of ~100k, what is the best practice for draining/dropping/clearing/deleting all messages using gcloud-java SDK?
Possible solutions:
Deleting and recreating the subscribers and then the publishers
High concurrency pull+ack (easy to hit the quota this way)
Something else
My hope is that this process can be fast (not more than ~60 seconds, say), robust, and uses supported SDK methods with minimal other code.
Update with description of snapshot and seek feature:
One can use seek on a Pub/Sub subscription to ack older messages by seeking to a timestamp corresponding to now. The best way is via the gcloud command line tool. The command to acknowledge messages published up to a particular timestamp would be:
gcloud pubsub subscriptions seek <subscription path> --time=yyyy-mm-ddThh:mm:ss
To delete all messages up to now:
gcloud pubsub subscriptions seek <subscription path> --time=$(date +%Y-%m-%dT%H:%M:%S)
Previous answer prior to the addition of snapshot and seek:
Currently, Google Cloud Pub/Sub has no way clear older messages, though it is something we are looking to add. Deleting and recreating the subscription would be the most efficient way to clear it, both in terms of time and cost. You wouldn't have to do anything with your publishers; any messages published from the point after recreation on will be sent to subscribers on the recreated subscription.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I plan to run Solr cores for multiple clients. I thought Linode offers solid performance, stability and a scalable upgrade plan.
Solr is a high-performance full text search engine, written as a REST app in JSP. A source whom I look up to says that disk-intensive apps dont scale as gracefully as CPU-intensive tasks in a VPS environment. So, past a "point", if I am serving twice as many clients, I should order twice as many instances, rather than upgrading them. Or I need cloud services with load-balancing such as EC2, where multiple instances scale gracefully.
Is this true, especially for a modern host like Linode?
It is true that Solr is a disk-IO-intensive application. We run Websolr in Amazon EC2 and have spent a lot of time benchmarking and tuning both their instance stores and EBS RAID devices in order to get the best price to performance ratio that we can.
Really, the best answer for you here will be to benchmark your disk performance and compare a few different setups. Measure IO operations per second, read and write bandwidth, and create some timed Solr benchmarks as well. (Large reindexing task, large search volume, etc.) Compare those to some different setups and see which one gives you the most favorable price to performance ratio.