The L2 CPU cache is not managed by SQL Anywhere; it is managed by the operating system. The amount that the L2 cache that will be used is defined by the registry key 'SecondLevelDataCache', available on some Windows platforms. See your operating system documentation for more info about controlling the L2 cache size.
As with all performance tuning recommendations, "it depends" on your workload type whether the extra L2 cache makes a difference. For instance, the related CPU time on a query may not be relevant if your query is really I/O-bound and most of the execution time is spent working against the disk. In that particular use-case, "all CPUs wait at the same speed", so the L2 cache usage on the CPU isn't really going to be a factor.
As John mentions here, some server threads do try to maintain processor affinity to try to eliminate the need for moving large amounts of information around in the processor caches.
The best way to decide if a bigger L2 cache really makes a difference to your workload is to set up a well-designed performance test, that will control for as many performance factors as possible.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.