limitation on shdict get_keys(0) ?

joe · 2014-12-19T02:23:57+00:00

Hello! On Mon, Jan 26, 2015 at 5:35 PM, zetao.wei wrote: > > openresty will support tcp/udp proxy > Not only tcp/udp proxies but also more genera...

limitation on shdict get_keys(0) ?

joe

Hi all,

I am able to normally curl a function that gets the total number of keys shared in the shared.dict by calling dict:get_keys(0)

location /printsize {
     content_by_lua '
            local dict = ngx.shared.rubes
            local keys = dict:get_keys(0)
            ngx.say(#keys, " key/value pairs inserted.")
        ';
}

However, recently I have been getting empty responses when I curl. Are there limitations on get_keys(0)? Perhaps when the dict reaches a certain size?

Thank you in advance

agentzh

Hello!

On Thu, Dec 18, 2014 at 10:23 AM,  joe wrote:
> I am able to normally curl a function that gets the total number of keys
> shared in the shared.dict by calling dict:get_keys(0)
>
> location /printsize {
>      content_by_lua '
>             local dict = ngx.shared.rubes
>             local keys =  dict:get_keys(0)
>             ngx.say(#keys, " key/value pairs inserted.")
>         ';
> }

This is way too expensive just for this. Maybe we can expose a size()
method for shdict.

>
> However, recently I have been getting empty responses when I curl. Are there
> limitations on get_keys(0)? Perhaps when the dict reaches a certain size?
>

What do you see in your nginx error logs?

Regards,
-agentzh

brian

get_keys was never intended for large amounts of keys. I was surprised to see that people are using it. It "blocks" all activity on a shdict, so it should be used sparingly. any logs (especially debug) would be helpful.

joe

Ah looks like it ran out of memory when I was looking for the size. Is shdict a valid use case for storing up to 10gb in memory or are we stretching its abilities?

nginx: lua atpanic: Lua VM crashed, reason: not enough memory
2014/12/18 20:27:02 [notice] 6653#0: gracefully shutting down
2014/12/18 20:27:02 [notice] 6653#0: exiting
2014/12/18 20:27:02 [notice] 6653#0: exit
2014/12/18 20:27:15 [notice] 9360#0: signal 17 (SIGCHLD) received
2014/12/18 20:27:15 [notice] 9360#0: worker process 6653 exited with code 0
2014/12/18 20:27:15 [alert] 9360#0: shared memory zone "rubes" was locked by 6653
2014/12/18 20:27:15 [notice] 9360#0: start worker process 11100
2014/12/18 20:27:15 [notice] 9360#0: signal 29 (SIGIO) received
2014/12/18 20:27:15 [notice] 11100#0: sched_setaffinity(0x00000004)

On Thursday, December 18, 2014 4:49:45 PM UTC-5, Brian Akins wrote:

get_keys was never intended for large amounts of keys. I was surprised to see that people are using it. It "blocks" all activity on a shdict, so it should be used sparingly. any logs (especially debug) would be helpful.

agentzh

Hello!

On Tue, Dec 23, 2014 at 8:20 AM,  joe wrote:
> Ah looks like it ran out of memory when I was looking for the size. Is
> shdict a valid use case for storing up to 10gb in memory or are we
> stretching its abilities?
>
> nginx: lua atpanic: Lua VM crashed, reason: not enough memory

shdict itself does not have any size limit but the GC-managed memory
in the LuaJIT VM does (the limit is 1GB on x86_64). Use of such huge
GC-managed memory in the LuaJIT is a clear indication of the misuse of
the get_keys() method.

Regards,
-agentzh

itspuneet59

Hello,

Are you talking about the maximum size a shared dict can have or a
single object inside the shared dictionary(key, value) can have?


Thanks and Regards
Puneet

On Wed, Dec 24, 2014 at 12:56 AM, Yichun Zhang (agentzh)
<age...@gmail.com> wrote:
> Hello!
>
> On Tue, Dec 23, 2014 at 8:20 AM,  joe wrote:
>> Ah looks like it ran out of memory when I was looking for the size. Is
>> shdict a valid use case for storing up to 10gb in memory or are we
>> stretching its abilities?
>>
>> nginx: lua atpanic: Lua VM crashed, reason: not enough memory
>
> shdict itself does not have any size limit but the GC-managed memory
> in the LuaJIT VM does (the limit is 1GB on x86_64). Use of such huge
> GC-managed memory in the LuaJIT is a clear indication of the misuse of
> the get_keys() method.
>
> Regards,
> -agentzh.

joe

I'll go into my use case a bit further. We have a shdict that is allocated 10gb of memory. Our nginx instance (as reverse proxy) gets about 20K requests per second and each request reads the shdict map and every few minutes the shdict is populated with a few thousand entries by a separate process. The reason why I was curious on the limitations of get_keys(0) and the memory limitation of shdict was that we were seeing nginx disconnecting connections rapidly to the server.

Perhaps it's not the correct use of shdict of that size with 20K reads per second? If I grep for not enough memory in the logs, I actually do not see any (other than the times I get_keys(0) )

Thank you

On Wednesday, December 24, 2014 1:47:52 AM UTC-5, itspuneet59 wrote:

Hello,

Are you talking about the maximum size a shared dict can have or a
single object inside the shared dictionary(key, value) can have?

Thanks and Regards
Puneet

On Wed, Dec 24, 2014 at 12:56 AM, Yichun Zhang (agentzh)
<age...@gmail.com> wrote:
> Hello!
>
> On Tue, Dec 23, 2014 at 8:20 AM, joe wrote:
>> Ah looks like it ran out of memory when I was looking for the size. Is
>> shdict a valid use case for storing up to 10gb in memory or are we
>> stretching its abilities?
>>
>> nginx: lua atpanic: Lua VM crashed, reason: not enough memory
>
> shdict itself does not have any size limit but the GC-managed memory
> in the LuaJIT VM does (the limit is 1GB on x86_64). Use of such huge
> GC-managed memory in the LuaJIT is a clear indication of the misuse of
> the get_keys() method.
>
> Regards,
> -agentzh.

rpaprocki

I would be curious to see why you need to search the entire key space, e.g. what the structure of your shdict looks like. Doing a linear (O(2n)) search of a large key space 20000 times a second seems incredibly inefficient. Seems like your use case might need to be refactored, rather than stretch the limits of the lua VM.

On Dec 24, 2014, at 6:47, j...@actionx.com wrote:

I'll go into my use case a bit further. We have a shdict that is allocated 10gb of memory. Our nginx instance (as reverse proxy) gets about 20K requests per second and each request reads the shdict map and every few minutes the shdict is populated with a few thousand entries by a separate process. The reason why I was curious on the limitations of get_keys(0) and the memory limitation of shdict was that we were seeing nginx disconnecting connections rapidly to the server.

Perhaps it's not the correct use of shdict of that size with 20K reads per second? If I grep for not enough memory in the logs, I actually do not see any (other than the times I get_keys(0) )

Thank you

On Wednesday, December 24, 2014 1:47:52 AM UTC-5, itspuneet59 wrote:
Hello,

Are you talking about the maximum size a shared dict can have or a
single object inside the shared dictionary(key, value) can have?

Thanks and Regards
Puneet

On Wed, Dec 24, 2014 at 12:56 AM, Yichun Zhang (agentzh)
<age...@gmail.com> wrote:
> Hello!
>
> On Tue, Dec 23, 2014 at 8:20 AM, joe wrote:
>> Ah looks like it ran out of memory when I was looking for the size. Is
>> shdict a valid use case for storing up to 10gb in memory or are we
>> stretching its abilities?
>>
>> nginx: lua atpanic: Lua VM crashed, reason: not enough memory
>
> shdict itself does not have any size limit but the GC-managed memory
> in the LuaJIT VM does (the limit is 1GB on x86_64). Use of such huge
> GC-managed memory in the LuaJIT is a clear indication of the misuse of
> the get_keys() method.
>
> Regards,
> -agentzh.

joe

Wouldn't get(key) be a O(1)? Perhaps i don't understand how the search in shdict works in depth. Sorry if I wasn't clear I only used get_keys(0) to get the total number of keys not to search.

On Wednesday, December 24, 2014 11:43:53 AM UTC-5, rpaprocki wrote:

I would be curious to see why you need to search the entire key space, e.g. what the structure of your shdict looks like. Doing a linear (O(2n)) search of a large key space 20000 times a second seems incredibly inefficient. Seems like your use case might need to be refactored, rather than stretch the limits of the lua VM.

On Dec 24, 2014, at 6:47, j...@actionx.com wrote:

I'll go into my use case a bit further. We have a shdict that is allocated 10gb of memory. Our nginx instance (as reverse proxy) gets about 20K requests per second and each request reads the shdict map and every few minutes the shdict is populated with a few thousand entries by a separate process. The reason why I was curious on the limitations of get_keys(0) and the memory limitation of shdict was that we were seeing nginx disconnecting connections rapidly to the server.

Perhaps it's not the correct use of shdict of that size with 20K reads per second? If I grep for not enough memory in the logs, I actually do not see any (other than the times I get_keys(0) )

Thank you

On Wednesday, December 24, 2014 1:47:52 AM UTC-5, itspuneet59 wrote:
Hello,

Are you talking about the maximum size a shared dict can have or a
single object inside the shared dictionary(key, value) can have?

Thanks and Regards
Puneet

On Wed, Dec 24, 2014 at 12:56 AM, Yichun Zhang (agentzh)
<age...@gmail.com> wrote:
> Hello!
>
> On Tue, Dec 23, 2014 at 8:20 AM, joe wrote:
>> Ah looks like it ran out of memory when I was looking for the size. Is
>> shdict a valid use case for storing up to 10gb in memory or are we
>> stretching its abilities?
>>
>> nginx: lua atpanic: Lua VM crashed, reason: not enough memory
>
> shdict itself does not have any size limit but the GC-managed memory
> in the LuaJIT VM does (the limit is 1GB on x86_64). Use of such huge
> GC-managed memory in the LuaJIT is a clear indication of the misuse of
> the get_keys() method.
>
> Regards,
> -agentzh.

rpaprocki

get_keys() is O(2n)) based on reading the source. I would assume get() is close to constant (plus some epsilon based on the size), but if you're running get_keys() every request it's easy to see where that can be a constraint.

"Sorry if I wasn't clear I only used get_keys(0) to get the total number of keys not to search."

I'm a little confused by this, without knowing more about the logic in your key/value logic it's hard to comment. It seems if you have a large data store it might be more stable to hold it in something like Redis.

On Dec 24, 2014, at 9:39, j...@actionx.com wrote:

Wouldn't get(key) be a O(1)? Perhaps i don't understand how the search in shdict works in depth. Sorry if I wasn't clear I only used get_keys(0) to get the total number of keys not to search.

On Wednesday, December 24, 2014 11:43:53 AM UTC-5, rpaprocki wrote:
I would be curious to see why you need to search the entire key space, e.g. what the structure of your shdict looks like. Doing a linear (O(2n)) search of a large key space 20000 times a second seems incredibly inefficient. Seems like your use case might need to be refactored, rather than stretch the limits of the lua VM.

On Dec 24, 2014, at 6:47, j...@actionx.com wrote:

I'll go into my use case a bit further. We have a shdict that is allocated 10gb of memory. Our nginx instance (as reverse proxy) gets about 20K requests per second and each request reads the shdict map and every few minutes the shdict is populated with a few thousand entries by a separate process. The reason why I was curious on the limitations of get_keys(0) and the memory limitation of shdict was that we were seeing nginx disconnecting connections rapidly to the server.

Perhaps it's not the correct use of shdict of that size with 20K reads per second? If I grep for not enough memory in the logs, I actually do not see any (other than the times I get_keys(0) )

Thank you

On Wednesday, December 24, 2014 1:47:52 AM UTC-5, itspuneet59 wrote:
Hello,

Are you talking about the maximum size a shared dict can have or a
single object inside the shared dictionary(key, value) can have?

Thanks and Regards
Puneet

On Wed, Dec 24, 2014 at 12:56 AM, Yichun Zhang (agentzh)
<age...@gmail.com> wrote:
> Hello!
>
> On Tue, Dec 23, 2014 at 8:20 AM, joe wrote:
>> Ah looks like it ran out of memory when I was looking for the size. Is
>> shdict a valid use case for storing up to 10gb in memory or are we
>> stretching its abilities?
>>
>> nginx: lua atpanic: Lua VM crashed, reason: not enough memory
>
> shdict itself does not have any size limit but the GC-managed memory
> in the LuaJIT VM does (the limit is 1GB on x86_64). Use of such huge
> GC-managed memory in the LuaJIT is a clear indication of the misuse of
> the get_keys() method.
>
> Regards,
> -agentzh.

brian

Using shdict is fine for a lot of data. 10gb is not that much. However, counting the keys x time per second using get_keys is not a good approach as it loads all the keys into RAM. I would suggest keeping track of the number of keys in a different way or perhaps patching the code to keep track of the number of items (not sure how hard this would be). We may should put a stronger warning in the docs for get_keys. My original use case was for a shdict that stored config values - a couple of dozen keys max.

Sent from my iPhone

On Dec 24, 2014, at 1:05 PM, Robert Paprocki <rpap...@fearnothingproductions.net> wrote:

get_keys() is O(2n)) based on reading the source. I would assume get() is close to constant (plus some epsilon based on the size), but if you're running get_keys() every request it's easy to see where that can be a constraint.

"Sorry if I wasn't clear I only used get_keys(0) to get the total number of keys not to search."

I'm a little confused by this, without knowing more about the logic in your key/value logic it's hard to comment. It seems if you have a large data store it might be more stable to hold it in something like Redis.

On Dec 24, 2014, at 9:39, j...@actionx.com wrote:

Wouldn't get(key) be a O(1)? Perhaps i don't understand how the search in shdict works in depth. Sorry if I wasn't clear I only used get_keys(0) to get the total number of keys not to search.

On Wednesday, December 24, 2014 11:43:53 AM UTC-5, rpaprocki wrote:
I would be curious to see why you need to search the entire key space, e.g. what the structure of your shdict looks like. Doing a linear (O(2n)) search of a large key space 20000 times a second seems incredibly inefficient. Seems like your use case might need to be refactored, rather than stretch the limits of the lua VM.

On Dec 24, 2014, at 6:47, j...@actionx.com wrote:

I'll go into my use case a bit further. We have a shdict that is allocated 10gb of memory. Our nginx instance (as reverse proxy) gets about 20K requests per second and each request reads the shdict map and every few minutes the shdict is populated with a few thousand entries by a separate process. The reason why I was curious on the limitations of get_keys(0) and the memory limitation of shdict was that we were seeing nginx disconnecting connections rapidly to the server.

Perhaps it's not the correct use of shdict of that size with 20K reads per second? If I grep for not enough memory in the logs, I actually do not see any (other than the times I get_keys(0) )

Thank you

On Wednesday, December 24, 2014 1:47:52 AM UTC-5, itspuneet59 wrote:
Hello,

Are you talking about the maximum size a shared dict can have or a
single object inside the shared dictionary(key, value) can have?

Thanks and Regards
Puneet

On Wed, Dec 24, 2014 at 12:56 AM, Yichun Zhang (agentzh)
<age...@gmail.com> wrote:
> Hello!
>
> On Tue, Dec 23, 2014 at 8:20 AM, joe wrote:
>> Ah looks like it ran out of memory when I was looking for the size. Is
>> shdict a valid use case for storing up to 10gb in memory or are we
>> stretching its abilities?
>>
>> nginx: lua atpanic: Lua VM crashed, reason: not enough memory
>
> shdict itself does not have any size limit but the GC-managed memory
> in the LuaJIT VM does (the limit is 1GB on x86_64). Use of such huge
> GC-managed memory in the LuaJIT is a clear indication of the misuse of
> the get_keys() method.
>
> Regards,
> -agentzh.

agentzh

Hello!

On Thu, Dec 25, 2014 at 8:11 AM, Brian Akins wrote:
> Using shdict is fine for a lot of data. 10gb is not that much. However,
> counting the keys x time per second using get_keys is not a good approach as
> it loads all the keys into RAM.

Yes, get_keys(0) loads *all* the key contents from the shm zone into
the Lua GC-managed memory, which means creating a *lot* of Lua strings
and a *huge* Lua table for for counting the number of keys, which is
completely waste of resources, and can easily exceed the limit in
LuaJIT's GC-memanged memory (as having said, 1GB on x64).

Abusing get_keys() is very bad. That's also why I was hesitate to add
this to shdict in the first place.

For the original poster's use case, one should either maintain the
count with a special key itself, or just use external tools based on
systemtap or dtrace. As I've said, we could add a count() method to
shdict to count all the non-expired key-value pairs though it is still
an O(n) operation (but without importing any data from shdict into the
Lua space). Well, patches welcome.

It's not easy to make it O(1) because we have to take into account key
expiration.

Regards,
-agentzh

joe

Thank you for all the responses! I might be beating a dead horse here (and that's mostly my fault for not being clear. I will fix that for future posts) but I still wanted to know if our group were using shdict correctly for our use case.

*I'm doing get_keys(0) at a rate of 20,000 per second.

What we are doing are the following:
    doing a get() at a rate of 20K per second
    doing a set() at a rate of 700 a minute without exptime
    Once a day we also do a larger insert to the shdict (around 20K sporadically over 2 hours).

The team noticed that the size of shdict was growing in memory (near the allotted amount of 10gb) and were concerned if there were any problems reading a map of that size at a rate of 20K per second AND also have an insert every few minutes. I figured that at a certain point the set() and get() would interfere with each other. I am assuming that when shdict runs out of memory, the set() would take longer to execute as it needs to push out the ids using the LRU algo and locking the shdict, causing the get() to take longer and causing response timeouts for our clients.

These are speculations as we haven't observed it yet(though we do see the occasional timeouts from clients) and we wanted to be prepared to scale in the case the clients wanted to increase their QPS.

Thank you and happy almost new year!

On Thursday, December 25, 2014 6:05:09 PM UTC-5, agentzh wrote:

Hello!

On Thu, Dec 25, 2014 at 8:11 AM, Brian Akins wrote:
> Using shdict is fine for a lot of data. 10gb is not that much. However,
> counting the keys x time per second using get_keys is not a good approach as
> it loads all the keys into RAM.

Yes, get_keys(0) loads *all* the key contents from the shm zone into
the Lua GC-managed memory, which means creating a *lot* of Lua strings
and a *huge* Lua table for for counting the number of keys, which is
completely waste of resources, and can easily exceed the limit in
LuaJIT's GC-memanged memory (as having said, 1GB on x64).

Abusing get_keys() is very bad. That's also why I was hesitate to add
this to shdict in the first place.

For the original poster's use case, one should either maintain the
count with a special key itself, or just use external tools based on
systemtap or dtrace. As I've said, we could add a count() method to
shdict to count all the non-expired key-value pairs though it is still
an O(n) operation (but without importing any data from shdict into the
Lua space). Well, patches welcome.

It's not easy to make it O(1) because we have to take into account key
expiration.

Regards,
-agentzh

brian

agentzh can answer about how the eviction works. It's been a while since I dug into the code. I can say that the use case you presented is not that unusual. I had a service that did much more than that with no issues. While I was never able to get to the bottom of it before I had to move on to different projects, at very high request rates, I would see contention on the spin locks and I wound up "hashing" into multiple shdicts. The rate was much, much higher than what you are describing though.

On Tue, Dec 30, 2014 at 12:52 PM, <j...@actionx.com> wrote:

Thank you for all the responses! I might be beating a dead horse here (and that's mostly my fault for not being clear. I will fix that for future posts) but I still wanted to know if our group were using shdict correctly for our use case.

*I'm doing get_keys(0) at a rate of 20,000 per second.

What we are doing are the following:
    doing a get() at a rate of 20K per second
    doing a set() at a rate of 700 a minute without exptime
    Once a day we also do a larger insert to the shdict (around 20K sporadically over 2 hours).

The team noticed that the size of shdict was growing in memory (near the allotted amount of 10gb) and were concerned if there were any problems reading a map of that size at a rate of 20K per second AND also have an insert every few minutes. I figured that at a certain point the set() and get() would interfere with each other. I am assuming that when shdict runs out of memory, the set() would take longer to execute as it needs to push out the ids using the LRU algo and locking the shdict, causing the get() to take longer and causing response timeouts for our clients.

These are speculations as we haven't observed it yet(though we do see the occasional timeouts from clients) and we wanted to be prepared to scale in the case the clients wanted to increase their QPS.

Thank you and happy almost new year!

On Thursday, December 25, 2014 6:05:09 PM UTC-5, agentzh wrote:
Hello!

On Thu, Dec 25, 2014 at 8:11 AM, Brian Akins wrote:
> Using shdict is fine for a lot of data. 10gb is not that much. However,
> counting the keys x time per second using get_keys is not a good approach as
> it loads all the keys into RAM.

Yes, get_keys(0) loads *all* the key contents from the shm zone into
the Lua GC-managed memory, which means creating a *lot* of Lua strings
and a *huge* Lua table for for counting the number of keys, which is
completely waste of resources, and can easily exceed the limit in
LuaJIT's GC-memanged memory (as having said, 1GB on x64).

Abusing get_keys() is very bad. That's also why I was hesitate to add
this to shdict in the first place.

For the original poster's use case, one should either maintain the
count with a special key itself, or just use external tools based on
systemtap or dtrace. As I've said, we could add a count() method to
shdict to count all the non-expired key-value pairs though it is still
an O(n) operation (but without importing any data from shdict into the
Lua space). Well, patches welcome.

It's not easy to make it O(1) because we have to take into account key
expiration.

Regards,
-agentzh

.

agentzh

Hello!

On Tue, Dec 30, 2014 at 9:52 AM,  joe wrote:
> The team noticed that the size of shdict was growing in memory (near the
> allotted amount of 10gb) and were concerned if there were any problems
> reading a map of that size at a rate of 20K per second AND also have an
> insert every few minutes.

The shared dictionary API uses a red-black tree under the hood. So for
normal cases, the time complexity is O(log n) where n is the number of
elements (or key-value pairs) in the store.

The larger the data set, the slower the access time. Though it grows
as log(n) instead of n.

Whether the current speed is satisfactory for your use case, you have
to benchmark (and also profile) the performance yourself.

> I figured that at a certain point the set() and
> get() would interfere with each other. I am assuming that when shdict runs
> out of memory, the set() would take longer to execute as it needs to push
> out the ids using the LRU algo and locking the shdict, causing the get() to
> take longer and causing response timeouts for our clients.
>

According to the current shdict implementation, both get() and set()
hold a mutex lock for the whole shm store. We could optimize this
locking mechanism for high read/write ratio cases so as to
significantly reduce the lock overhead under high concurrency level
and large data set. This is a TODO and patches welcome :)

> These are speculations as we haven't observed it yet(though we do see the
> occasional timeouts from clients) and we wanted to be prepared to scale in
> the case the clients wanted to increase their QPS.
>

I suggest tracing the root causes those timeouts with tools like
systemtap instead of guessing :)

Also, the on-CPU and off-CPU flame graph tools are almost always
helpful to get insights:

http://openresty.org/#Profiling

At last but not least, the manual sharding over multiple different
lua_shared_dict in the same server can reduce the locking effects for
big data set a lot, as already suggested by Brian Akins :)

Regards,
-agentzh

joe

Thank you for your responses. I'm interested in the possible locking mechanism for a high read/write ratio case. Rookie question here, but are we talking about an optimistic lock mechanism like with databases or a different type of mechanism where we perhaps lock a part of the dictionary when writing?

Thank you

On Friday, January 2, 2015 at 5:49:30 PM UTC-5, agentzh wrote:

Hello!

On Tue, Dec 30, 2014 at 9:52 AM, joe wrote:
> The team noticed that the size of shdict was growing in memory (near the
> allotted amount of 10gb) and were concerned if there were any problems
> reading a map of that size at a rate of 20K per second AND also have an
> insert every few minutes.

The shared dictionary API uses a red-black tree under the hood. So for
normal cases, the time complexity is O(log n) where n is the number of
elements (or key-value pairs) in the store.

The larger the data set, the slower the access time. Though it grows
as log(n) instead of n.

Whether the current speed is satisfactory for your use case, you have
to benchmark (and also profile) the performance yourself.

> I figured that at a certain point the set() and
> get() would interfere with each other. I am assuming that when shdict runs
> out of memory, the set() would take longer to execute as it needs to push
> out the ids using the LRU algo and locking the shdict, causing the get() to
> take longer and causing response timeouts for our clients.
>

According to the current shdict implementation, both get() and set()
hold a mutex lock for the whole shm store. We could optimize this
locking mechanism for high read/write ratio cases so as to
significantly reduce the lock overhead under high concurrency level
and large data set. This is a TODO and patches welcome :)

> These are speculations as we haven't observed it yet(though we do see the
> occasional timeouts from clients) and we wanted to be prepared to scale in
> the case the clients wanted to increase their QPS.
>

I suggest tracing the root causes those timeouts with tools like
systemtap instead of guessing :)

Also, the on-CPU and off-CPU flame graph tools are almost always
helpful to get insights:

http://openresty.org/#Profiling

At last but not least, the manual sharding over multiple different
lua_shared_dict in the same server can reduce the locking effects for
big data set a lot, as already suggested by Brian Akins :)

Regards,
-agentzh

agentzh

Hello!

On Fri, Jan 9, 2015 at 11:35 AM,  joe wrote:
> Thank you for your responses. I'm interested in the possible locking
> mechanism for a high read/write ratio case. Rookie question here, but are we
> talking about an optimistic lock mechanism like with databases or a
> different type of mechanism where we perhaps lock a part of the dictionary
> when writing?
>

I think we can just use simple RW locks:

    http://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock

In case of ngx_lua's shdict:

1. Writing to the red-black tree always requires an exclusive lock on
the whole tree due to the rebalancing.

2. For get() calls, we still need to update the LRU queue which
requires exclusive locking though no exclusive locks required on the
red-black tree for all the readers.

Regards,
-agentzh