|
hello I am new to sqlanywhere I am using the -c option to set the initial ammount of memory, i have set the option in syabase central. when I start the service and look in task manager I can see that the service has not claimed the ammount of memory I have set, have I understood the -c option does it not set the ammount of ram the service should claim at start ? i have set -c 1500m thank you for your response. |
|
Use SELECT PROPERTY ( 'CurrentCacheSize' ) to determine how big the cache is, in kilobytes. The -c option specifies the initial value, and the actual value can change over time unless you also specify -ca 0 to turn off automatic cache sizing. You can also control the minimum and maximum cache sizes with -cl and -ch. The memory numbers in Task Manager are not very useful IMO. If SQL Anywhere is sharing a computer with other applications than automatic cache sizing is a wonderful thing for varying workloads. However, if the computer is dedicated to an industrial-strength SQL Anywhere database then settings like -c 90p -ca 0 make sense (cache size fixed at 90% of physical memory). The rule of thumb is "you can never have too much cache". And to directly address the disconnect between cache size and the value in the task manager: the task manager shows the process' "working set size", not the amount of allocated memory. To see the amount of memory allocated by the process, use perfmon and look at the "Process/Private Bytes" counter.
(23 Apr '14, 16:29)
John Smirnios
Breck, why? ".. with more chace we don't have better performance? Thanks
(23 Apr '14, 20:04)
DRauber
Replies hidden
1
Yes, that is what I am saying... with more cache you have better performance. Another way of saying that is that "too much cache" is an impossibility. It is like saying "you can never have too much money" :)
(23 Apr '14, 20:51)
Breck Carter
Hm, I like your original rule of thumb more - the cited statement is certainly correct when cache itself is a limitation (and that will be true in many cases). However, if you are using a database that "fits into the current cache" (including memory for heavy queries and the like) - not unlikely for "small" embedded databases -, more cache won't necessarily lead to better performance, just as a faster processor won't help when I/O is the bottleneck... On the other hand, it won't reduce performance, either, therefore it's a reasonable rule of thumb:)
(24 Apr '14, 02:58)
Volker Barth
sorry, messed up the translation! I am Brazilian and my English is poor: (
(24 Apr '14, 07:45)
DRauber
2
I wouldn't worry - you are making yourself understood, which is a lot more than I could in Portuguese :)
(24 Apr '14, 08:30)
Justin Willey
|
