Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
There are different things you can try.
You could use a different queue-set to allocate all your buffer resources to the single queue you're using. (Don't forget to zero out the 3 other queue buffer reservations.)
If your not using an uplink port for your Metro hand-off, you might try that. Cisco documents the 3750X has 2 MB of buffer RAM for each set of 24 downlink ports, and 2 MB of buffer RAM for the uplink ports. Don't know what buffer RAM resources are on different 3560/3750 models, but suspect similar resource allocations. (i.e. uplinks ports get more buffer space per port)
If not already doing so, you might shutdown ports not being used. This might release those ports' buffer space.
As you hub has 20 Mbps available, you could split your sites across to shaped queues, each getting 10 (or so) Mbps. This would take advantage of your additional hub bandwidth w/o risking overrunning any one spoke. It will complicate buffer sharing, now you'll need to split buffers across both queues. You can try 50% reserved for each, or nothing reserved for each, or something in between. Hard to say which will work best for you.
Ideally, if you split your spokes across two shaped queues, you'll round-robin them on their average bandwidth consumption (this to insure best average usage of your bandwidth).
Lastly, there's my Rube Goldberg suggestion. If your 3560 had 48 copper ports, and 4 uplinks, you take LAN input on a gig uplink, then you can have 24 copper ports connected to the other 24 copper ports. Each set in a different VRF. This would allow you to run each port at 10 Mbps, and support 4 classes of service. The combined aggregate uses another uplink port connected to another uplink port, with another VRF, both running at 100 Mbps (requires multispeed copper SFP) but port limited to 20%. Again, your can support 4 classes of service. The last port, the remaining uplink, is used to connect to your MetroE at gig.
What the forgoing would allow would be, up to, 24 logical pipes running at 10 Mbps, each supporting 4 classes of service. You determine what maps to each logical pipe. The aggregate of the 24 logical pipes maps to another 20 Mbps pipe, also supporting 4 classes of service.
Basically your 10 Mbps logical pipes keep from overrunning spokes, but if there's more than 10 Mbps of traffic, you can provide up to 4 different class treatments. The aggregate is limited to your hub's 20 Mbps, again allowing you to provide 4 different class treatments.
An ISR, with its much more advanced QoS, does the above in software, and you can have more than 4 different classes.
