You're right, you wouldn't really see the burstiness easily on SNMP. 1GE can send 1.48Mpps, so it takes very very little time to congest the the 45Mbps, which can handle less than 75kpps.
If your ingress is 1GE and egress is 45Mbps, then obviously the congestion point of 45Mbps will need to drop packets. This is normal and expected. If you increase buffers you'll introduce more delay.
1GE takes 0.45ms to send 40 1500B IP frames, which is right now the amount of burst you can handle. However dequeueing them on the 45Mbps already takes 10ms.
If you don't have any acute problem, I would probably not do anything about it. But if some traffic is more eligible for dropping than other, then you should replace FIFO with class-based queueing. Say maybe you want to prioritize so that more ftp is dropped and less voip.
Then it'll also make more sense to add more buffering on the ftp traffic, as it's not really sensitive to delay.
If you want to try your luck with deeper buffers, something like this should suffice:
policy-map WAN-OUT
class class-default
fair-queue
queue-limit 200 packets
!
interface Serial1/0
service-policy output WAN-OUT
This would cause 50ms buffers on the Serial1 and would allow you to handle up-to 2.25ms burst from single Gige interface.
Just like BGP attributes are packed when sending BGP UPDATEs, they are stored in memory in a rather compact format where each prefixes only holds references to the attributes that apply to that route. The AS path and the communities applied to a route are typically the attributes that are largest in size and as these are often the same over a large amount of routes, a great deal of memory can be saved by just storing an AS path once and then keeping references to all routes for which this AS path applies. The exact in-memory format changes with different versions of IOS/JUNOS.
A route for the same prefix received via different eBGP sessions will likely share many attributes (especially if the eBGP sessions are to the same upstream) and so they can be "packed" quite efficiently in memory.
Your explanation of BGP behaviour is mostly correct. R1 has sent the content of its entire BGP RIB to R2. R2s eBGP session is enablde and for every route received, R2 will compare it to the one in its BGP RIB (which mostly contains routes from R1). When R2 finds a prefix from its new eBGP peer that is better than the one in BGP RIB, it will use the new eBGP route and announce it to R1. If R1 finds the route received from R2 to be better than its own route (received from its eBGP session) then R2 will withdraw the route that it announced to R2. The routers will only announce their best route and if the best route is not from eBGP but from another iBGP neighbor, it will not announce it unless you have some route-reflection going on as well. You can easily end up in a scenario where both R1 and R2 each select all the routes learnt from their respective eBGP session as the best routes and that means they will always announce a full table to their iBGP buddies.
There's also something called "best external" which means you always announce your best eBGP route regardless if that's the one you have chosen as best path or not. Best external enhances convergence time by not having to go through "BGP path hunting" when something breaks. Obviously it consumes more memory.
Personally I don't think BGP Soft reset enhancement is much of an enhancement. RAM is cheap, so keeping the routes, exactly as received from your neighbor, in memory is quite easy, especially on a modern router. JUNOS doesn't even offer you the option to not store it - it always keeps the Adj-RIB-IN, but JUNOS was designed in the late 90s when RAM was plentiful and not in the 80s when IOS made the scene. If someone out there designing a router thinks "let's save on RAM because we have BGP soft reset enhancement", I'd like to shoot that person ;)
On the other hand, if you are running a network with old routers running low on memory I totally understand if you don't enable soft-reconf.
Bottom line, it's difficult to say and depends on your environment.
Best Answer
There are two issues here:
BGP keepalives are 60 seconds, and the hold down timer is 3 times that. So that's your lower limit, unless you work with your carrier and adjust your timers. You both need to have the same timer values.
You are receiving full routes from both carriers. That's over 400,000 routes from each carrier. So your router needs to process that many entries when a carrier drops a session. That can take time on a small router like a 2900.
One idea is to only receive default routes from your carrier. You can still use local preference to prioritize carriers, but it's much faster to process one route than 400,000. Don't forget that you are still limited by #1.