The main reason why you're overengineering is because you already have one verified problem: Your lock routine is absolutely guaranteed known to be wrong.
In the general practice of troubleshooting software, if you have known issues fix those right away. Removing one known bug will help isolate and narrow down any futher bugs you have. More often than not the problem will completely go away and you'll save yourself the time of having tried eight things before fixing one of them. In short: Fix one thing at a time. Adhere to this and your salary will slowly grow as you fix problems faster and more reliably than you did before. On Sat, 4 Jun 2016, Nishant Varma wrote: > Thanks. Can you please tell me why you say that I am overengineering. Maybe I > am but I wanted good reasons so that I convince myself. The problem is some > times locks are not > happening like say 2-3 times out of 3000 requests, and I have only 4 reasons > so far - 1) get-set race 2) memcache client disconnects 3) data eviction 4) > some ordinary coding > issues (of which I don't see any evidence so far and the ratio suggests > otherwise?). Also do you have any other ideas to take this forward, let me > know. I wanted to see if it > is set-get race mainly or else just rule out concurrency as the first step. > > On Saturday, June 4, 2016 at 1:35:37 PM UTC+5:30, Dormando wrote: > Hey, > > Memcached can't do that easily right now. You can use the STDOUT logging > but that requires reading everything the server is doing directly. > > I started a branch for a better logging situation a few months ago, and > am > picking it up to finish over the next few weeks > (https://github.com/memcached/memcached/pull/127). That won't do you any > good in the short term though. > > Printing via your overrides is probably the best way of getting the > localized data you need, however I insist *again* that you're > overengineering this. > > On Sat, 4 Jun 2016, Nishant Varma wrote: > > > Real time of offline solutions would be helpful. If I can profile in > background and query it later that is one option. However the only concern > with profiling is > that I don't > > need to profile everything. Or does memcache do this by default? Can > anyone guide me? > > > > On Saturday, June 4, 2016 at 12:13:32 PM UTC+5:30, Nishant Varma > wrote: > > I am trying to troubleshoot an issue which could happen because > of get-set race condition. I can monitor the entire memcache operations but I > guess it is > going to > > be huge because its a small percentage of the DB itself, so I > need to filter only the keys I am interested in. We have a namespacing > convention to > distinguish our > > memcache entries so I would like to monitor the get and set > that happens to a specific namespace to track the get-set race condition. > > > > > > I have a client side solution which is to over-ride (decorator > in Python) memcache.get and memcache.set to print the arguments if the key > matches our > desired > > pattern. > > > > > > However can this be done in memcache server? We have so many > clients and we would have collect this information from all nodes and morover > this feels like > suited > > for server. Is there something that we could in memcached like > using debug module that would help us? > > > > > > This e-mail message (including any attachments) may contain > information that is confidential, protected by the attorney-client or other > applicable privileges, or > otherwise > > comprising non-public information. This message is intended to be > conveyed only to the designated recipient(s). If you have any reason to > believe you are not an > intended > > recipient of this message, please notify the sender by replying to > this message and then deleting it from your system. Any use, dissemination, > distribution, or > reproduction of > > this message by unintended recipients is not authorized and may be > unlawful. > > > > -- > > > > --- > > You received this message because you are subscribed to the Google > Groups "memcached" group. > > To unsubscribe from this group and stop receiving emails from it, > send an email to memcached+...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > > > > This e-mail message (including any attachments) may contain information that > is confidential, protected by the attorney-client or other applicable > privileges, or otherwise > comprising non-public information. This message is intended to be conveyed > only to the designated recipient(s). If you have any reason to believe you > are not an intended > recipient of this message, please notify the sender by replying to this > message and then deleting it from your system. Any use, dissemination, > distribution, or reproduction of > this message by unintended recipients is not authorized and may be unlawful. > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to memcached+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
